SDD Is Not Three Tools — It's a Stack of Eight Phases
Martin Fowler's piece on SDD tooling is worth reading. Fowler has a rare ability to name things precisely, and his framing of spec-driven development as a response to the "context collapse" problem in AI-assisted coding is the clearest articulation of the core problem I've seen in print.
But the analysis stops at three tools. And that stopping point obscures what makes SDD hard in practice.
What Fowler Gets Right
Fowler identifies the three tools that most SDD implementations converge on: a spec format, a validation mechanism, and an approval gate. He is correct that these three primitives are necessary. A spec without validation is a wish list. Validation without an approval gate produces thrash — agents implementing half-approved requirements and then reversing course.
His observation that the bottleneck has shifted from code generation to correctness verification is also accurate and underappreciated. The problem is not that AI agents write slowly. The problem is that they write confidently in the wrong direction when requirements are ambiguous — and no one notices until the feature ships.
Where the Three-Tool Frame Falls Short
The three tools Fowler describes — spec, validate, approve — cover the implementation loop. They do not cover what happens before it, or what happens after it.
Before implementation, there is a problem. A developer has an idea. That idea needs to be externalized (brainstorm), structured into acceptance criteria (spec), stress-tested for completeness (challenge), and checked for implementation readiness before any agent touches code (readiness check). These four phases happen before the approve step, and skipping them is why specs arrive at the approval gate with criteria too vague to implement correctly.
After merge, there is a different problem. Code that passes acceptance criteria at merge time can drift from the spec weeks later, as adjacent changes accumulate. Fowler's three tools have nothing to say about this. The approve-validate cycle ends at merge.
The Eight Phases
A complete SDD lifecycle has eight phases:
1. BRAINSTORM → capture the idea before it dissolves
2. SPEC → structure it into testable acceptance criteria
3. CHALLENGE → adversarially probe the spec for gaps and contradictions
4. READINESS CHECK → verify the spec is implementable before coding starts
5. APPROVE → human signs off on the contract
6. IMPLEMENT → agent executes against the spec
7. VALIDATE → verify implementation against each criterion
8. HEAL → retroactively detect and correct post-merge driftFowler's three tools map onto phases 5, 6, and 7. That leaves five phases uncovered.
The phases teams most commonly skip are 3 (challenge) and 8 (heal). Skipping challenge means acceptance criteria arrive at approval with hidden ambiguities that only surface during implementation. Skipping heal means drift accumulates silently after merge, and the spec becomes a historical artifact rather than a living contract.
Why This Matters for Tool Selection
If you evaluate SDD tools by asking "does it have a spec format, a validation mechanism, and an approval gate," almost every tool in the current landscape passes. That is the wrong question.
The right question is: which tool covers all eight phases, and which phases require manual intervention?
A tool that covers phases 5–7 but not 1–4 forces developers to manage the pre-implementation workflow outside the tool. The challenge and readiness check phases — which exist precisely to catch what humans miss — are absent.
A tool that covers phases 5–7 but not phase 8 treats merge as the end of the lifecycle. For long-lived codebases with frequent adjacent changes, this is a significant gap.
Fowler's Frame Is Still Useful
None of this is a criticism of Fowler's analysis. The three-tool frame is an accurate description of the minimum viable SDD workflow. For teams adopting SDD for the first time, phases 5, 6, and 7 are the right place to start — they deliver most of the value with the least overhead.
The frame becomes a ceiling when teams try to scale. At higher velocity, with parallel agents and long-lived specs, the phases outside the three-tool window create the friction that limits throughput.
The Full Stack
SDD tooling is not a feature checklist. It is a pipeline. The question is not whether a tool has spec support — it is whether the tool covers the pipeline end to end, including the phases that most analyses ignore.
Brainstorm to heal, without gaps.
Further reading: The Complete Guide to Spec Driven Development · Autonomous Mode: end-to-end SDD with /autonomous-sdd · Planu vs SDD Tools