There is a page on this site where I mapped the entire software lifecycle against AI: nine phases, the eight forces reshaping them, seventy two cells, each one an honest answer to what can AI do here. I still stand behind that map. But I have watched how it gets read, and too often it gets read like a menu. Eyes light up in thirty cells at once. That is the moment the map stops helping, because the question that decides whether any cell becomes real value was never on it: not what AI can do here, but what it is for, here, for us.
The model is the last decision in the chain, and the easiest. The use case is the first, and the hardest: where the knowledge lives, what a wrong answer costs, and who catches it before it ships.
- Why a capability map of AI across the lifecycle, including my own, answers the easy half of the question.
- Three questions that separate a use case from a demo, and the one answer that means no pattern will save you.
- A three rung ladder from prompting to grounding to teaching, and why the lightest rung that works is the right one.
The Question That Arrives Backwards
When AI comes up in a delivery organisation, the first question I hear is almost always a model name wearing a question mark. Which model should we standardise on. Which vendor, which platform, which licence. It arrives confident, budget attached, and it arrives backwards. Nobody has named the work yet. Nobody has said which phase of the lifecycle is bleeding hours, which knowledge the answers must come from, or who will be reading the output at the moment it is wrong.
This series opened with a discipline for exactly this failure: write the criteria before the shortlist, because whatever gets named first quietly becomes the anchor everything else is measured against. Choosing a model before naming the use case is the same bias in newer clothes. The tool is more impressive now. The mistake has not changed at all.
Capability is what the demo shows. A use case is a commitment: this work, this knowledge, this cost of being wrong, this person still accountable.
Where the Lifecycle Actually Wants Help
Read as an architect rather than a tourist, the lifecycle is a map of candidate use cases, and each phase has a different honest answer. Two columns matter for every phase: where AI genuinely earns a place, and where it will lie to you while looking helpful.
That table is deliberately small. The seventy two cell version lives in the practitioner’s map, phase by phase, force by force. What the small version adds is the column a capability map cannot carry: the specific way each phase’s help goes wrong. A use case is not a cell you point at. It is a cell you can defend.
Three Questions Find the Use Case
Across every phase, the qualifying interview is the same three questions. I ask them in this order, because each one is cheaper than the one after it, and a failure at any of them ends the interview politely.
Where does the knowledge live?
Three places, three verdicts. In the model already (public patterns, standard code, the world’s documentation): prompt it as it stands. In your documents and systems (your runbooks, your domain rules, your tickets, your wiki): the model must be grounded in them, because it cannot cite what it never read. In people’s heads: stop. No adaptation pattern retrieves what was never written down. That use case has a different name, knowledge capture, and it comes first.
What does a wrong answer cost?
A wrong draft costs a shrug; a reviewer was reading it anyway. A wrong answer to a customer costs trust. A wrong action against production costs the weekend, and sometimes the quarter. Price the wrongness honestly and the right amount of human stays in the loop by construction. Priced on enthusiasm, the human leaves the loop exactly where the cost is highest.
Who catches it before it ships?
A compiler, a failing test, a reviewer with time actually allocated: if a verifier stands between the model and the consequence, generation is safe to try. If nothing in that gap can say wrong, you have not found a use case. You have found a place to put an apology.
There is a quieter fourth question, and it is the commercial one: how often does the work repeat? A task that arrives twice a year does not earn a pipeline; it earns a prompt saved in a text file. Toil that arrives every day, in volume, with a shape, is where the engineering pays for itself. The best use cases are boring at demo time and priceless by the third week.
The Adaptation Ladder
Question one picks the rung. There are only three, and the discipline is to climb on evidence, never on ambition.
The rule underneath the ladder is one this series has already paid for: the lightest thing that works. And the model itself? Choose it last, the way you would choose a vendor: against the use case’s requirements, on paper, after the page below is filled in.
The demo that never meets a Tuesday
Use cases chosen by wow produce pilots, and pilots chosen by wow produce slide decks. The tell is a proof of concept that has never touched production data, never priced a wrong answer, and cannot name the person who reviews its output. A demo optimises for the applause in the room. A use case optimises for a Tuesday afternoon: unglamorous work, arriving constantly, wrong answers caught cheaply. If a pilot cannot say which phase it serves, which knowledge it draws on and who signs what it produces, calling it early is generous. It never started.
The use case record, one page
Phase. Task. Knowledge source. Cost of a wrong answer. Verifier. Rung. The metric that says it is working, and the date you will read that metric out loud. One page, argued over, signed. It is the same habit this series opened with, criteria written before options, kept where the next person can challenge them. An AI use case that cannot fill one page is not ready to leave it.
- Start from the work, not the model. Name the phase, the task and the toil before anyone names a vendor. A model name in the first sentence is the first anchor bias, restated.
- Ask where the knowledge lives. In the model: prompt. In your systems: ground. In people’s heads: write it down first, because nothing retrieves the unwritten.
- Price the wrong answer out loud. Then size the supervision to the price. The loop should lose its human where mistakes are cheap, and never anywhere else.
- Refuse use cases without a verifier. No test, check or reviewer between the model and the consequence means the use case is not ready, whatever the demo looked like.
- Climb the ladder on evidence. Prompt, then ground, then teach, each rung justified by the measured shortfall of the one below, recorded on a page somebody signed.
An architect does not adopt AI. An architect adopts use cases, one at a time, each with a written reason to exist and a test it must keep passing to stay.
The selection discipline is this essay; the practice behind each rung has a whole book. The AI in Practice guide walks it end to end: how the machine thinks, what agents actually need, what the leverage costs, and how it all gets secured. A different track, the same rule. The use case first.