For about twenty years, most IT organisations were built around three words: Plan, Build, Run. It was a good model. It gave everyone a place. Plan owned the budget and the roadmap. Build owned the code. Run owned the servers and the pager.
With AI agents and spec-driven development, that model no longer fits. What I see in real projects is four phases: Specify, Generate, Verify, Operate.
The interesting part is not the new names. It is the number. Three becomes four.
What was wrong with the old model
Nothing, for a long time. But it had one weak spot that we all learned to live with.
The specification was a side product. Someone wrote a document, the team read it once, the code was written, and after the release nobody touched the document again. Six months later, the only honest description of the system was the source code itself.
We accepted that. We even made a virtue out of it. “The code is the truth.” And in a world where humans write every line, that is a reasonable position. The person who writes the code holds the intent in their head.
An agent does not hold anything in its head. It only knows what you give it. So the moment you let an agent write code, the weak spot becomes the main problem.
Specify
Specify moves out of Build and becomes a phase of its own, with its own result.
This is a bigger shift than it sounds. In Plan-Build-Run, “Plan” meant portfolio, budget and roadmap. It was management work. The actual specification happened somewhere inside Build, often in a ticket, often in a conversation, often nowhere at all.
Now the specification is the input to the machine. It has to be precise enough that an agent can act on it. It has to be versioned, reviewed and maintained like code, because it is now the thing you keep.
In my work I use system use cases in the style of Alistair Cockburn for this. A main flow, alternative flows, preconditions, postconditions. Not because the format is magic, but because it is precise, it is small, and it is testable. A use case tells you what the system does and what has to be true afterwards. That is exactly what an agent needs, and it is exactly what a test needs.
The other thing that changes: business people can read a use case. They cannot read a prompt history.
Generate
Generate sounds like pressing a button. In a greenfield demo, it almost is. In an enterprise system with fifteen years of history, it is not.
If you point an agent at a large existing codebase with nothing but a specification, you get faster chaos. The agent does not know your module boundaries. It does not know that the OrderService is the one nobody is allowed to touch. It does not know that you use jOOQ and not Hibernate, or that your team has a rule about where transactions start.
The work is in the harness. That means the rules, the context, the project structure, the build, the linters, the architecture tests, the traceability from a use case to the code that implements it. The harness is what turns a general model into something that can work in your system.
This is where most of the effort goes, and it is the part that nobody puts on a slide. Generate is cheap. The harness is not.
Also worth saying: Generate does not mean the developer disappears. It means the developer moves up. You review, you decide, you correct the specification when the generated code shows that the specification was wrong. That last part happens more often than you would think, and it is a feature.
Verify
Verify is the genuinely new phase, and I think it is the most important one.
We always tested. But testing was hidden inside Build. It shared a budget with feature work, it shared a deadline with feature work, and when the deadline got tight, it was the first thing to be cut. Every one of us has seen that happen.
When code is generated fast, that arrangement breaks. Output goes up, review capacity stays the same. If you keep testing as a sub-task of Build, you have built a machine that produces plausible code faster than anyone can check it. That is not a productivity gain. That is a risk you have not measured yet.
So Verify becomes its own phase with its own budget and its own owner. And it is more than unit tests:
- Does the code do what the specification says? This is where traceability earns its money. If every use case maps to code and to a test, you can answer the question instead of guessing.
- Does the code fit the architecture? Architecture tests, dependency rules, module boundaries.
- Is the specification itself right? An agent will implement a wrong specification perfectly. That is the failure mode nobody is used to yet.
The last point is the uncomfortable one. In the old world, a developer would often catch a bad requirement while implementing it. That informal safety net is gone. Verify has to replace it on purpose.
Operate
Operate stays Operate. Software runs, and it does not care who wrote it.
Monitoring, logging, incidents, capacity, cost. All of that is the same. If anything, it gets more important, because production is now the place where you find out whether your specification described the real world or only the world you imagined.
One small addition: the feedback from Operate should go back into the specification, not only into the code. If you fix an incident by changing code and leave the use case untouched, the next generation run will happily reintroduce the bug. I have seen this happen. It is a very modern kind of regression.
The sentence this is really about
Until now, the code was the asset. Now the specification is the asset, and the code is a result you can produce again.
That is the whole thing in one line. Everything else follows from it. Why Specify gets its own phase. Why Verify needs a budget. Why the feedback loop from Operate has to end up in the specification.
It also changes what you buy when you buy software, and what you own when a supplier leaves. If you get the code but not the specification, you got the smaller half.
The objection
Someone always says it, so let me say it first: “You only renamed things and pulled testing out of Build.”
Yes. That is a fair description.
And that is the point. When something gets its own name, it gets an owner, a budget and a place in the plan. When it is a sub-task, it gets cut. This is not a technical argument, it is an organisational one, and organisational arguments are the ones that decide whether a practice survives contact with a real project.
Please do not build three new departments
Plan-Build-Run turned into three silos with three bosses in a lot of companies. Requirements were thrown over a wall to Build, and Build threw a release over a wall to Run. We spent fifteen years and a whole DevOps movement tearing those walls down again.
Do not rebuild them with new labels. Specify-Generate-Verify-Operate is a loop inside one team, not a new org chart. The same people should write the specification, run the generation, check the result and carry the pager. A separate Verify department would be the worst possible outcome of this article.
What you can do on Monday
If you want to try this without restructuring anything:
- Take one feature that is coming up. Write it as a system use case before anyone writes code. Main flow, alternatives, postconditions.
- Put it in the repository, next to the code, in version control.
- Give it to an agent together with your project rules, and see what comes back.
- Check the result against the use case, not against your memory of the meeting.
- When the result is wrong, ask whether the specification was wrong. Fix the specification first, then regenerate.
That is one loop. You will learn more from one honest loop than from any framework description, including this one.
Keep IT simple
Four phases instead of three. One new phase that we always did but never named. And one shift in what we treat as valuable.
That is all it is. It is not a revolution, and I would be careful with anyone who sells it as one. It is a small correction to a model that served us well and now needs one more box.
