What is spec-driven development?
Spec-driven development is a workflow in which a coding agent builds against a written specification that a human reviews before any code exists. No single person is credited with coining the name for the AI era: Kiro’s launch post used it on 14 July 2025 and GitHub’s Spec Kit followed on 2 September 2025. Vendors present it as the step after vibe coding, not its opposite.
Origin No single person is credited with coining it for the AI era: the earliest uses the research found are Kiro’s launch post of 14 July 2025 (opens in a new tab), GitHub’s Spec Kit post of 2 September 2025 (opens in a new tab) and Tessl’s launch post of 16 September 2025 (opens in a new tab), and the phrase has academic prior art from 2004.
Also on Wikipedia (opens in a new tab), Wikidata (opens in a new tab)
- In Polish
- Programowanie sterowane specyfikacją
- Closest ladder level
- Level 4, free guide
- Also searched as
- SDD, spec driven development, specification-driven development
Then $19.99 a month or $99.99 a year. Cancel from your account page. 30-day refund on a first purchase.
Why it matters.
A spec moves the human’s reading from the diff to a document: you review what should be built before the agent builds it, and tests guard the result. That holds only while the spec stays true, because an agent believes whatever the spec says. This site therefore asks for one authoritative spec.md, a spec delta in every pull request that changes behaviour, and a test behind each requirement. The label proves little on its own: a framework adds ceremony, and it does not make a spec true.
Spec-driven development vs vibe coding
The vendors that launched the term set it against vibe coding as the step for serious work; our reading is that the two sit in sequence more than in opposition.
| Question | Vibe coding | Spec-driven development |
|---|---|---|
| What it names | A way of working: accept the model’s output without reading it | A workflow: a reviewed spec, plan and task list come before any code |
| Who writes the code | The model | The agent, from the approved spec |
| Who checks it | Nobody reads the diff; the human judges behaviour by eye | Humans review the spec, plan and tasks; tests guard the result |
| What stops the loop | The human decides it works | The task list is done and the acceptance criteria pass (our reading) |
| Where the name came from | Andrej Karpathy, post on X, 2 February 2025 | No single AI-era coiner; Kiro, 14 July 2025; GitHub Spec Kit, 2 September 2025 |
| Where it breaks | Anything others maintain; Karpathy called it fine for “throwaway weekend projects” | A spec nobody keeps true misleads the agent, and critics see waterfall in the paperwork (Marmelab, 12 November 2025) |
Three levels of spec-driven development
Birgitta Böckeler of Thoughtworks separates three ways to use a spec, and found that all the approaches she looked at are spec-first while not all aim higher.
| Level | Böckeler’s definition (15 October 2025) |
|---|---|
| Spec-first | “A well thought-out spec is written first, and then used in the AI-assisted development workflow for the task at hand.” |
| Spec-anchored | “The spec is kept even after the task is complete, to continue using it for evolution and maintenance of the respective feature.” |
| Spec-as-source | “The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code.” |
spec.md, kept true by a spec delta in every pull request that changes behaviour. Our reading: that is spec-anchored.Spec-driven frameworks: first public dates
These are the AI-era launches the research could date from a project’s own post or repository, in order, with what each says it writes before code.
| Project | Dated by | What it writes before code |
|---|---|---|
| Kiro (AWS) | 14 July 2025, launch post | Requirements as user stories with EARS acceptance criteria, then a design, then tasks |
| OpenSpec (Fission AI) | 5 August 2025, repository created | A change proposal with spec deltas; archiving merges them into openspec/specs/ |
| GitHub Spec Kit | 2 September 2025, launch post (repository created 21 August 2025) | A constitution, then a spec, plan and task list per feature, in one folder per feature |
| Tessl | 16 September 2025, product launch post | Specs that capture intent, backed by tests and “hard guardrails” |
Questions about spec-driven development.
How is spec-driven development different from vibe coding?
Vibe coding accepts the agent’s output without reading it; spec-driven development has humans review the spec, plan and tasks first, with tests guarding the result. GitHub’s launch post says vibe coding “can be great for quick prototypes, but less reliable when building serious, mission-critical applications”. Our reading: the vendors present spec-driven development as the step after vibe coding, not its enemy.
Who coined spec-driven development?
No single person is established for the AI era. The phrase has academic prior art in a 2004 paper by Ostroff, Makalsky and Paige. Kiro’s launch post used it on 14 July 2025, GitHub’s Spec Kit post on 2 September 2025 and Tessl’s on 16 September 2025. Birgitta Böckeler wrote on 15 October 2025 that “the definition of ‘spec-driven development’ (SDD) is still in flux”.
Is spec-driven development the same as AI-DLC?
No. AI-DLC is AWS’s lifecycle and team method, introduced on 31 July 2025, which replaces sprints with “bolts” of hours or days. Spec-driven development is a practice about one artefact, the spec. This site’s frameworks guide does list AI-DLC among the spec-first pipelines, where its distinguishing feature is an audit trail of approvals.
Is spec-driven development just waterfall?
Critics say it can be. Marmelab’s François Zaninotto wrote on 12 November 2025 that it “revives the old idea of heavy documentation before coding”, and described an agent marking a “verify implementation” task done “without writing a single unit test”. Our reading: the risk is real when the spec drifts from the code, so this site’s guide asks for a spec delta in every behaviour-changing pull request and a test behind each requirement.
The vocabulary of AI-driven development
Every name below is defined against vibe coding: who writes the code, who checks it, and what stops the loop.
Read the long-form guide: agentic engineering vs vibe coding
Sources.
The primary sources outside this site that this page relies on.
- Introducing Kiro (opens in a new tab) Nikhil Swaminathan and Deepak Singh, Kiro
- Spec-driven development with AI: Get started with a new open source toolkit (opens in a new tab) Den Delimarsky, The GitHub Blog
- Announcing Tessl’s Products to Unlock the Power of Agents (opens in a new tab) Guy Podjarny, Tessl
- Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl (opens in a new tab) Birgitta Böckeler, martinfowler.com
- Spec-Driven Development: The Waterfall Strikes Back (opens in a new tab) François Zaninotto, Marmelab
- AI-Driven Development Life Cycle: Reimagining Software Engineering (opens in a new tab) Raja SP, AWS DevOps & Developer Productivity Blog
Keep reading.
The guides that go deeper, and the terms and comparisons next to this one.
In the docs
- The full A-Z glossarySubscription
- Vibe coding vs agentic engineering: 21 terms comparedFree
- Level 4: You Write the SpecsFree
- Spec-driven development: the spec as the source of truthSubscription
- Spec-driven frameworks compared: Spec Kit vs OpenSpec vs BMAD vs SuperpowersSubscription
- GitHub Spec Kit: spec-driven development in practiceSubscription
- OpenSpec: change proposals and living specsSubscription
Related terms
Comparisons
Read the guides in the same words.
Open every guide with the 7-day free trial. Each term is defined once here, and the guides use it the same way.
Then $19.99 a month or $99.99 a year. Cancel from your account page. 30-day refund on a first purchase.