What spec-driven development is
Spec-driven development (SDD) is a way of building software in which a clear, structured specification is the primary source of truth, and code is produced from it rather than the other way around. The spec captures what you are building and why: the intent, the domain concepts, the constraints, the acceptance criteria, and the design decisions. Implementation, whether written by a person or generated by an AI agent, follows the approved spec.
This inverts the habit most teams built up over a decade of agile practice, where the code was the artifact that mattered and any written spec drifted out of date the moment it was committed. SDD keeps the spec in the loop: it is reviewed, approved, versioned, and used as the brief that drives the build.
Why it emerged now
SDD is not a new idea in spirit. Engineers have written design docs and RFCs for decades. What changed is the economics. Generative AI made producing code close to free, and that shifted the bottleneck. When a model can turn a paragraph into a working module in seconds, the limiting factor is no longer typing speed. It is whether the paragraph described the right thing.
A one-line prompt produces a plausible-looking answer to a question nobody fully specified, and the industry gave that output a name: AI slop. The cost lands downstream. The CloudBees 2026 State of Code Abundance Report and the Sonar State of Code Developer Survey 2026 report AI-assisted code producing roughly 1.7 times more correctness issues than human-authored code, and VentureBeat reports around 43 percent of AI-generated changes needing production debugging even after passing QA. The fix is not slower AI. It is a better brief. If the spec is precise and reviewed, the generated code has something correct to be generated from.
Code got cheap, so the spec became the scarce artifact. Spec-driven development is what you do once you accept that the spec, not the code, is where quality is won or lost.
How it works in practice
Concrete implementations vary, but the shape is consistent. SDD runs as a loop with a review checkpoint before expensive, hard-to-reverse work:
The review checkpoint is the whole point. It moves the moment of catching a misunderstanding from after the code is written, where it is expensive, to before, where it is a comment on a document.
What a good spec contains
Not every document that calls itself a spec is one. A one-line prompt is not a spec; neither is a wall of prose with no structure. A spec that actually drives quality tends to carry a few things:
- Intent and value. What is being built and why it matters, stated plainly enough that a reviewer can judge whether it is the right thing at all.
- Domain concepts. The entities and business rules involved, named in the vocabulary of the existing system rather than invented fresh, so new work fits what is already there.
- Scope boundaries. What is in, and just as importantly what is out, so the build does not quietly expand.
- Acceptance criteria. Testable conditions (often written as Given / When / Then) that define done and give verification something concrete to check.
- Constraints and standards. The non-negotiables: the patterns the team follows, the limits that must not be crossed, the decisions already made.
The landscape of approaches
By 2026 nearly every AI coding player ships a flavor of SDD, and they cluster into a few families. They are genuinely different tools for different situations, not straight substitutes:
| Family | Examples | Where the spec lives | Best for |
|---|---|---|---|
| Repo-native | GitHub Spec Kit, OpenSpec, BMAD | Markdown files in the repository, versioned in git | Solo developers and single-repo teams who live in the codebase |
| Spec-aware IDEs | Kiro, agentic editors | Inside the editor, guiding the developer at the keyboard | Individual developers who want spec structure in their flow |
| Governed team platforms | REEZN | A shared workspace with enforced roles and approvals | Product-plus-engineering teams who need the spec reviewed and governed, not just written |
The repo-native tools deserve real credit. Spec Kit is free, open source, and excellent for a developer working alone or a small team comfortable reviewing specs as pull-request diffs. If that is you, they may be all you need, and their price is hard to argue with. The spec-aware IDEs bring the same discipline into the editor, which is a natural home for the developer already there.
The gap those approaches share is structural rather than a matter of quality: they are built for the developer at the keyboard. A spec that lives as a file in a repo is not a place a product manager can review, and nothing in a repo blocks an unreviewed change from shipping. That is the space governed team platforms address. REEZN is one: it runs the same specify-review-implement-verify loop as a team workflow, where product and engineering approve together, and standards, safeguards, and sign-offs are enforced by the platform rather than by discipline.
Common failure modes
SDD is not automatic. Teams adopt it and still ship slop when the practice degrades in predictable ways:
- Specs nobody reviews. If the spec is written and then rubber-stamped, it is theater. The review gate has to be real, with someone empowered to send it back.
- Specs that drift from code. A spec written once and never reconciled with what was actually built rots into fiction. It has to stay the source of truth through implementation and verification, not just at kickoff.
- Product excluded by the medium. When the spec is a markdown file in a pull request, the people who own the requirements cannot participate. The workflow silently becomes engineering-only, and requirements bugs slip through because the person who would have caught them never saw the document.
- Structure-free specs. A freeform brief lets every author skip a different section. A consistent structure is what guarantees no two specs forget the same thing.
Where the practice is heading
The clear direction of travel is from individual discipline to team governance. The first wave of SDD tooling helped one developer get better output from AI. The next wave is about a whole team: shared standards applied to every spec automatically, organizational memory so plan number fifty is written knowing everything plans one through forty-nine established, and enforced approval so speed never quietly costs rigor.
As AI agents take on more of the implementation, the spec and its review gates become the primary way a team agrees on what gets built and gets it built right the first time, rather than steering an agent diff by diff after the fact. That is the plane where spec-driven development stops being a developer productivity trick and becomes how a team keeps quality in hand while AI does the building.
REEZN publishes its own opinionated, governed flavor of this practice openly, called SPDD (Structured Prompt Driven Development). It is a concrete worked example of the loop described here, and it is free to read and adopt with any stack.