Spec-Driven Development
Write the spec before the code, and treat the spec as the source of truth the AI implements from. The durable artifact becomes the natural-language specification; code is "the last-mile."
Spec-driven development (SDD) is the practice of writing a structured, behavior-oriented specification in natural language before AI-assisted coding, and using that spec as guidance for the coding agent. The premise: as agents do more of the typing, the human's work moves up a level, to expressing intent precisely. GitHub frames it as "the lingua franca of development moves to a higher level, and code is the last-mile." Source: B. Bockeler / Martin Fowler, https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html, 2026-05-31
Three variants
The term is still in flux. Bockeler distinguishes three levels of commitment:
- Spec-first - a spec is written first and used for the task at hand, then set aside.
- Spec-anchored - the spec is kept after the task and reused to evolve and maintain the feature over time.
- Spec-as-source - the spec is the primary source file; the human edits only the spec and never touches the generated code.
Most current tooling is spec-first in practice, even when it aspires to spec-anchored. Source: Fowler/Bockeler, sdd-3-tools, 2026-05-31
The tools (as of 2026)
- Kiro (AWS) - the most lightweight, largely spec-first, oriented around a single task or user story.
- spec-kit (GitHub) - a CLI that scaffolds files for many coding assistants and drives a
specify, plan, tasksworkflow via slash commands. Its "constitution" is an immutable, always-applied rules file, and each step uses checklists as an AI-interpreted definition of done. - Tessl - the only one explicitly aiming at spec-anchored, spec-as-source.
Source: Fowler/Bockeler, sdd-3-tools, 2026-05-31
Verify, do not just steer
The recurring warning: the human's job is not only to direct the agent but to verify at each phase, "you reflect and refine." A spec that is approved without scrutiny launders a bad design into a lot of code fast. This is why SDD pairs with an explicit review gate. Source: Fowler/Bockeler, sdd-3-tools, 2026-05-31
Relation to the wiki
SDD is the artifact-centric cousin of plan-mode review and the brainstorm-then-plan-then-build flow Kevin already enforces. The "constitution" idea is Constraints over Context in text form, immutable rails the agent must honor, and the verify-don't-just-steer rule is Empirical Verification applied to specs. The spec is to code what the harness is to a coding loop: the durable structure that survives the disposable output.
Concept Position
| Field | Value |
|---|---|
| Concept family | Brain, memory, and retrieval |
| Concept owned | Write the spec before the code, and treat the spec as the source of truth the AI implements from. The durable artifact becomes the natural-... |
| Category map | Concept System Map |
Timeline
- 2026-07-01 | Concepts category refresh added this page to the Brain, memory, and retrieval family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: Write the spec before the code, and treat the spec as the source of truth the AI implements from. The durable artifact becomes the natural-... Source: User request, 2026-07-01
- 2026-05-31 | Page created from Martin Fowler's SDD article by Birgitta Bockeler. Captured the spec-as-source-of-truth premise, the spec-first/anchored/as-source variants, the Kiro/spec-kit/Tessl survey (including spec-kit's "constitution" and checklists), and the verify-not-just-steer rule. Source: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html, 2026-05-31