English | EN 
Part 1 – Why the spec, not the prompt, is becoming software’s real product
It’s 4:47 on a Friday, and the release that went out at lunch is why nobody has left yet. An AI agent had built a refund endpoint from a two-line prompt. It compiled, passed every test, and got approved in four minutes because it read like solid code.
What nobody noticed until a customer complained: it reversed the payment before checking whether the order had already shipped. Nobody had told the AI that shipped orders needed a different flow, because nobody had written it down anywhere. That’s not really a story about a bad model. It’s a story about a missing sentence.
The brilliant intern problem
I call this the “brilliant intern problem.” Hand a sharp intern a vague brief and they won’t come back empty-handed – they’ll come back confident, having quietly filled every gap with their own best guess. Most guesses are fine. Occasionally one is expensive, and you don’t find out which until it’s live. AI agents behave the same way, just a thousand times faster.
AI can now write in minutes what used to take days, but velocity without governance is just risk moving faster. Industry estimates put it starkly: nearly three-quarters of AI-generated code needs rework before it merges, and teams without clear specs report roughly three times more debugging time than teams that specify intent up front. Every retro has a version of the same line: “the code looked right, so nobody questioned it.”
An AI agent given a vague instruction doesn’t fail loudly. It fails confidently – a far more dangerous kind of failure.
What’s changed my thinking isn’t a clever prompting trick – it’s an old idea, re-applied: write down what you mean before you ask for the code. The industry calls this Spec-Driven Development (SDD), and just about every major AI vendor in the market has converged on some version of it within the same eighteen months, independently and without coordinating. Fierce competitors rarely agree on anything voluntarily. When most of them do, at the same time, that’s a structural shift, not a trend.
Flipping the order of operations
Traditional delivery goes: idea, code, test, bugs, patch, and maybe documentation afterward, as a courtesy. SDD inverts that. The spec comes first and isn’t a courtesy – it’s what everything else gets measured against. Code becomes a generated, validated artifact of the spec, not the other way round.
If the spec is the source of truth, an AI agent isn’t guessing at intent from a two-line prompt anymore. Ambiguity gets resolved on paper, where it’s cheap to fix, instead of in production, where it almost never is. In practice this plays out as six stages, each producing an artifact the next depends on: a standing constitution rules out the non-negotiables once; a spec captures what a feature must – and must never – do; a clarify pass hunts for ambiguity before design starts; a plan locks the technical contracts; tasks break it into agent-sized units; and only then does an agent implement, against a document that already contains the sentence missing from the story above.
Coming up in Part 2:
→ How much spec rigor any one piece of work actually deserves
→ The three levels of SDD maturity – and where most enterprise teams should aim
→ What changes for product owners, architects, developers, and QA