For thirty years the scarce resource in software was people who could turn an ambiguous request into working code. The ambiguity was absorbed quietly, by developers asking questions in corridors and making reasonable guesses. It was inefficient and it was invisible, and it worked.
An agent does not absorb ambiguity. It resolves it, instantly and confidently, in whatever direction the prompt happened to point. That single property is why the specification has stopped being paperwork and become the thing that determines the output.
What a usable specification contains
Most organisations that say they write specifications are writing wish lists. The difference shows up immediately when an agent acts on them.
A specification an agent can build from, and a human can verify, states four things.
The outcome, in the business’s terms. Not “add a filter to the reporting screen” but “a regional manager can see the ten stores with the worst stock cover this week, and the definition of stock cover is this formula.” The first is a feature request; the second constrains what correct means.
The rules, including the ones everybody knows. Institutional knowledge that lives in three people’s heads is exactly what an agent cannot see. Which customers are exempt, what happens at the end of the fiscal year, which product categories behave differently and why. This is the slowest part to write and the part that determines whether the output is usable.
The edge cases, decided rather than discovered. What happens with no data, with negative values, with a record that exists in one system and not the other. Every one of these will be decided by somebody. The choice is whether it gets decided by the business in advance or by a model at three in the morning.
The test that proves it works. Written before the build, in terms the business would accept. Without it, “done” collapses back to “the code was merged”, which is the definition that stopped meaning anything the moment code became cheap.
Who writes it
Not the technology function alone, which does not hold the rules. Not the business alone, which will not reach the required precision unaided. The arrangement that works is the business owning the specification with technical support, and the same models everyone is deploying used to help write and stress-test it.
That last point matters more than it sounds. The most reliable early use of AI in a slow organisation is not generating code. It is interrogating a draft specification: what have you not said, what contradicts what, what happens in this case you have not mentioned. It is unglamorous, it is fast, and it attacks the part of the process that was actually the bottleneck.
Why organisations resist it
Writing things down precisely exposes disagreement. A vague requirement lets three stakeholders believe they are getting three different things and postpones the argument until delivery, when it is someone else’s problem. Precision forces the argument forward into a room where it has to be settled.
That is the real cost of spec-driven development, and it is a cost that lands on business leaders rather than on engineers. It is also the entire point. Organisations do not get slow because people write code slowly. They get slow because decisions are deferred, and a specification is an instrument for forcing decisions to happen early.
How to start without a programme
Take one initiative that matters and is currently stuck. Write the specification properly, with the four elements above, and put a named business owner on it. Time how long that takes, and time how long the build takes afterwards. Then compare both against the last comparable thing the organisation delivered.
The comparison tends to settle the argument faster than any presentation. Specification takes longer than anyone expects and the build collapses to a fraction of what it used to be, and once a team has seen that ratio once they do not go back voluntarily.
What it does to the organisation
Three consequences follow, and they should be planned for rather than discovered.
The definition role becomes senior and central, when for a decade it was being quietly deleted from organisation charts as an artefact of waterfall. It is coming back, with different tooling and a different name, and the people who can do it are not currently in the roles that reward it.
Review capacity becomes the constraint. When building is cheap, the bottleneck is the number of people who can competently judge whether what came back is right. That capacity has to be built deliberately, because it used to be a by-product of writing the code.
And the argument moves earlier. Meetings get harder at the start of an initiative and much easier at the end, which is a trade most boards would take and most middle management resists, because the discomfort is immediate and the payoff is a quarter away.