Spec-driven development
Intent as the source of truth, code as a regenerable artifact.
Once the system is machine-readable, the method has to change too. The old default was code as truth. The agentic default is intent as truth.
The summary
The gist in a few sentences, then the full argument for this layer.
We used to throw the spec away and call the code the truth. Agents flip that: the spec becomes the source of truth, and the code is a last-mile output you can regenerate.
How far you push it is a choice, not a ladder. Birgitta Böckeler's three levels run spec-first, spec-anchored, spec-as-source; match the level to the cost of drift.
Keep the soft spots in: heavy up-front specs and brownfield maintenance are real costs, so the human verifies the logic at every gate.
We used to throw the spec away and call the code the truth. AI agents killed that habit. Prompt an agent ad hoc, like a search engine, and you get vibe coding: intent drift, context decay, output nobody can verify. The fix is a flip. The spec becomes the source of truth, and the code becomes a last-mile output you can tear down and regenerate when the requirements change.
That is spec-driven development. The spec, not the code, is the thing you version, review, and trust. Code compiles from intent the way a binary compiles from source.
Why it works comes down to one fact about LLMs: they are great at pattern completion and useless at mind reading. A precise spec strips out the thousands of assumptions an agent would otherwise guess at, and accuracy climbs. AWS Kiro, for one, reports turning roughly forty-hour features into about eight hours of human time.
The shape has settled into a four-phase loop: Specify, Plan, Tasks, Implement. Write the rules once in an AGENTS.md constitution. Write acceptance criteria in EARS, the five-pattern syntax that makes requirements machine-checkable. And put a human checkpoint at every phase boundary, because the real failure mode is letting an agent run from prompt straight to merge with nobody verifying the spec.
How far you push this is a choice, not a ladder. Birgitta Böckeler's three levels run from spec-first (write a spec to guide the build, often discard it after), to spec-anchored (the spec stays alive and governs the feature), to spec-as-source (you only ever edit the spec and never touch the generated code). Spec-first is where nearly everyone actually is, so match the level to the cost of drift, not to rigor you will not enforce.
Keep the soft spots in view, because the people closest to this do. Böckeler, who drew the map, is openly skeptical of heavy up-front specs, and warns that spec-as-source could inherit the worst of both worlds: the inflexibility of old model-driven development and the non-determinism of LLMs. Specs on existing, messy code are still immature, and practitioners like Romina Kavcic put the ongoing maintenance at something like a third of the effort. Anyone selling this as free is not running it.
Velocity in AI engineering does not come from generating code faster. It comes from getting the intent right before the agent writes a line. Spec first, verify at every gate, regenerate freely. But intent only pays off if it reaches the agent at the moment it acts, and that delivery is the runtime layer's job.
The narrated overview
The same layer, heard. Self-hosted and played from a token-driven player.
The annotated sources
The originals, each with one line on why it matters. The annotation is the judgment, and the judgment is the authority.
- Intro GitHub on spec-driven development GitHub's own intro to SDD, with intent as the source of truth, straight from the source.
- Toolkit Spec Kit The reference toolkit for the Specify, Plan, Tasks, Implement loop.
- Repo Spec Kit repository The repo. Where Spec Kit actually lives and ships.
- Maturity Böckeler, the three levels Birgitta Böckeler, writing in Martin Fowler's Exploring Gen AI series, compares Kiro, Spec Kit, and Tessl. The spec-first, spec-anchored, spec-as-source levels are hers.
- Guide The long-form SDD guide The long-form 2026 guide. EARS, maturity levels, and the anti-patterns.
- Landscape The 2026 SDD tool roundup The tool landscape if you are choosing one: Kiro, BMAD, OpenSpec, and the rest.
The notebook
Interrogate the curated corpus directly, and ask the thing this page did not cover.
Try asking
- Which maturity level matches the cost of drift in your project?
- What does EARS notation buy you over a plain requirement?
- Where does spec-driven development still fall short today?
Spec-driven development, answered
The questions readers bring to this layer.
-
What is spec-driven development?
Spec-driven development makes a written, version-controlled spec the source of truth and treats the generated code as a regenerable artifact you can rebuild on demand. You protect the intent, not the code. GitHub frames it plainly in its Spec Kit intro: intent is the source of truth.
-
What is the difference between spec-first, spec-anchored, and spec-as-source?
They are three levels of investment, mapped by Birgitta Böckeler in Martin Fowler's Exploring Gen AI series. Spec-first: write a spec, often discard it after. Spec-anchored: the spec stays alive and governs the feature. Spec-as-source: you only edit the spec, never the generated code. Most teams are at spec-first.
-
What is EARS notation?
EARS, the Easy Approach to Requirements Syntax, is a five-pattern format that turns fuzzy requirements into testable, unambiguous statements an agent can't misread. Alistair Mavin and a team at Rolls-Royce created it in 2009 and presented it at the RE'09 conference. It is what makes acceptance criteria machine-checkable.
-
Does spec-driven development actually save time, or is it just overhead?
Both, and the honest answer matters. AWS Kiro reports turning roughly forty-hour features into about eight hours of human time. But specs on messy, existing code stay immature, and practitioners like Romina Kavcic put ongoing maintenance at about a third of the effort. Anyone selling it as free isn't running it.