English | EN 
Part 2 – How much rigor to apply, and what changes for the people around the code
Part 1 made the case that AI agents fail like brilliant interns: confidently, and only on the assumptions nobody wrote down. Spec-Driven Development (SDD) fixes that by flipping the order of operations – the spec becomes the source of truth and code becomes something generated and validated against it, rather than written first and documented later, if at all. Six stages carry that idea from constitution to implementation, each producing an artifact the next one depends on.
The obvious next question, and the one architects and delivery leads actually ask me: how much of this do you really need for this piece of work right now?
This isn’t one-size-fits-all
SDD isn’t all-or-nothing, and treating it that way is how good ideas get abandoned after one bad experience. There’s a real spectrum of how far to take it.
At the light end, the spec just guides the agent – good for early-stage, still-forming work. Further along, it becomes a contract: automated gates verify compliance, and multiple people or agents can share one source without drifting apart. That’s where most enterprise, regulated, or long-lived work should sit. At the far end, the spec generates the code directly, no manual edits at all – great for repetitive, well-tested, low-ambiguity work, riskier for complex production systems, where a slightly-wrong spec now costs a lot more.
The question was never “should we adopt this.” It’s “how much rigor does this particular piece of work deserve.”
A quick gut check usually settles it: is the requirement stable enough to write down? Will more than one person or agent touch it? Will it still be alive in three months? If the answer leans yes, a real spec pays for itself fast. If it leans no, a full spec is its own kind of waste.
It changes more than the code
The most underrated part of this shift is how much it changes for people who aren’t developers – it moves where judgment gets applied, for nearly every role.
The architect moves from auditor to author, encoding principles once instead of catching violations after they’ve already merged. The tester’s checklist moves from after the fact to before the first line of code, because verification criteria live inside the spec from day one. Judgment moves earlier in the timeline, and it moves into writing, where it can actually be checked.
Where I’d start
I wouldn’t suggest rewriting how a team works. Pick one real feature – enough stakes to matter, contained enough to fail safely – and run it through the discipline once: write the principles down, specify the outcome, hunt for the ambiguity, lock the contracts, then let an agent implement against all of it.
What usually follows isn’t a debate about methodology – it’s people noticing how much less arguing over “what did we actually mean” happens afterward.
AI hasn’t made engineering discipline optional. It’s made the absence of it more expensive, and far more visible, than it used to be.
Teams that treat the spec as the real product – and the code as something that follows from it – get to keep AI’s speed without paying for it later in rework, drift, and quiet production surprises. Spec first, code follows isn’t a new methodology so much as a returned one: an old engineering instinct, handed back to us at exactly the moment we need it most.