What is spec-driven development?
Engineering culture and software practice
Spec-driven development is a way of working with AI coding tools in which the team writes and maintains a precise specification of what the software must do, how it is structured and what constraints apply, and treats that specification, rather than a chat conversation, as the durable source from which code is generated and regenerated. The phrase spread through 2025 as a corrective to vibe coding, and the analyst firm Thoughtworks assessed it on its Technology Radar that year.
What this means
Spec-driven development says: before you let an AI build the thing, write down clearly what the thing is meant to do. That written specification becomes the anchor. When you want a change, you change the specification and regenerate, rather than nudging a chatbot in a conversation that nobody can find again next week.
The point is durability. A chat history is fragile: it is long, hard to review, and disappears into someone's account. A specification is a document a team can read, argue over, approve and keep. It is the difference between steering by conversation and steering by a shared, maintained plan.
This article uses the term in the sense most practitioners now mean: the specification as a governed artefact that drives AI-assisted building. It notes, but does not adopt, the more radical claim that the specification should replace code entirely, because as of September 2026 that view is contested even among its advocates.
Why it matters
For a non-engineer, the specification is the one artefact you can actually read and approve. You may never understand the code, but you can understand a plain-language statement of what the software must do and what it must never do. That makes spec-driven development a route to genuine oversight rather than blind trust.
It also addresses the biggest weakness of casual AI building: nobody can reconstruct why the software behaves as it does. If the specification is the source of truth, the reasoning is written down, reviewable and versioned, so a new team member or an auditor can follow it.
For ordinary firms, the habit matters more than any tool. Writing down intent, constraints and acceptance checks before building is good practice whether or not AI is involved. AI simply raises the stakes, because a machine will generate a great deal of code very fast from whatever instructions it is given, and a vague instruction produces a great deal of the wrong thing.
The practice is young and shaped by vendors, so a degree of caution is warranted. But the underlying idea, that a durable specification should govern generated code, connects directly to long-established engineering discipline rather than being a fashion.
How it works
Where the term came from
The phrase spec-driven development spread through 2025, driven by tooling launches and practitioner writing, as a reaction against the imprecision of vibe coding. Thoughtworks, a software consultancy whose Technology Radar is a widely read analyst source, placed spec-driven development in the Assess ring of its Radar volume published in November 2025, describing it as an emerging approach whose definition was still evolving. Vendor tools that carry the label include Amazon's Kiro, GitHub's spec-kit and the Tessl framework, named here only as facts of origin.
There is an honest dispute over what the term means. Some advocates argue the specification should become the sole maintained artefact, with code treated as a disposable by-product. Others, including many experienced engineers, hold that code remains the source of truth and the specification is one input that drives its generation, as tests do. Thoughtworks itself has flagged the term as prone to inconsistent use. Readers should expect the meaning to keep moving.
The lineage, by contrast, is old and well documented. Requirements specifications were codified in the IEEE 830 recommended practice, first issued as a guide in 1984. Bertrand Meyer introduced design by contract in 1986, formalising the obligations a piece of software must honour. Dan North described behaviour-driven development in 2006, promoting executable specifications written in shared language. And Donald Knuth introduced literate programming in a 1984 paper in The Computer Journal, arguing that a program should be written to be read by humans. Spec-driven development is these ideas meeting code-generating AI.
What a spec contains, and what it leaves out
In this practice a specification captures intent (what the software is for), constraints (what it must and must not do, including security and data rules), interfaces (how it connects to other things), and acceptance checks (how you will know it is right). It deliberately leaves out the implementation detail: the exact code, the line-by-line choices. The specification says what and why; the generation step handles how. Keeping that boundary is what makes the specification readable and durable.
The workflow
The loop runs: write the specification, let the tool produce a plan, generate the code, test it against the acceptance checks, and when something needs to change, change the specification rather than patching the code by hand. Over time the specification, not the chat log, is the thing the team maintains. This is what distinguishes it from prompting, where the instruction is transient and the code is edited directly.
How experienced teams handle it
Mature teams treat the specification as a governed document with a clear owner, kept under version control and reviewed like any other important artefact. They accept that specifications rot if neglected, that no specification can capture everything, and that the practice is still immature. So they pair it with testing and human review rather than trusting regeneration blindly. The specification is a tool for shared understanding, not a magic wand.
Examples
A professional services firm wants an internal tool to log client engagements. Rather than describing it to an AI in a live chat, the operations lead writes a one-page specification: what it must record, who may see what, which fields are mandatory, and how success will be judged. The tool is generated from that document, and when rules change, the document is updated and the tool regenerated. A partner with no technical background can read and approve the specification, which they never could have done with the code.
A charity replacing a spreadsheet-based volunteer system writes a plain-English specification covering the data it holds, the privacy constraints and the reports it needs. Because the constraints are written down, the security rules are visible to the trustees and to anyone who later maintains the system, rather than living only in a conversation that has since scrolled away.
A software team of eight adopts the habit for a new feature. They write the specification, generate and test against it, and keep the specification current as the source of shared understanding, while still treating the code as something to review and maintain. They gain a durable record of intent without pretending the specification alone guarantees correctness.
Common misunderstandings
The first misunderstanding is that spec-driven development is just careful prompting. It is not. A prompt is a transient instruction in a conversation; a specification is a durable, governed, reviewable artefact that outlives any single session. Unlike a prompt or a system prompt, the specification is meant to be maintained as the lasting source from which code is regenerated, rather than typed afresh each time.
The second is that it is a specific tool you buy. The practice is tool-agnostic. A small firm can adopt the habit with nothing more than a shared plain-language document; the tooling is optional and still immature.
The third is that the specification replaces code. That is one contested view, not settled fact. Many practitioners hold that code remains the source of truth and the specification is an input that drives it, and even the advocates disagree.
The fourth is that a specification, once written, is done. Specifications rot. If the software changes and the document does not, the specification becomes misleading, which is worse than having none.
The fifth is that a specification can capture everything. It cannot. Some intent is tacit, some constraints only emerge in use, and over-specifying can make the work harder rather than easier.
Risks and boundaries
This is a recent term in its current AI-assisted sense, popularised in 2025, and its meaning is still moving as of September 2026; this article was written in that month. The practice is vendor-shaped, and some of the enthusiasm around it is marketing rather than evidence. The claim that specifications can wholly replace code is a live and unresolved debate, not an established practice.
The boundaries are worth stating plainly. Spec-driven development does not remove the need for testing or human review. It does not guarantee correct or secure software; it makes intent explicit, which is necessary but not sufficient. And it is not a how-to or a tool endorsement: the durable value is the habit of writing down intent, constraints and acceptance checks before building, which stands on its own regardless of which, if any, tool a team adopts.
What to do next
Ask to see the specification for anything important being built with AI. If the only record of what the software should do is a chat history, treat that as a governance gap, not a detail.
Name an owner for each specification and keep it under version control alongside the code, so changes are reviewed and traceable. A specification with no owner will rot.
Insist that specifications include the acceptance checks: how anyone will know the software is right. Intent without a test of success is a wish, not a specification.
Adopt the habit before adopting any tool. Have teams write a plain-language statement of intent, constraints and acceptance checks for their next build. That discipline delivers most of the benefit and costs nothing.
FAQs
What is spec-driven development in plain terms?
Writing down clearly what software must do, then treating that document, rather than a chat conversation, as the durable source from which AI generates and regenerates the code.
When did the term become popular?
It spread through 2025 as a corrective to vibe coding, and Thoughtworks assessed it on its Technology Radar volume published in November 2025.
How is a spec different from a prompt?
A prompt is a one-off instruction in a conversation. A specification is a durable, reviewable, maintained artefact that governs the code over time.
Does spec-driven development replace code?
Some advocates argue it should; many experienced engineers disagree and hold that code remains the source of truth. As of September 2026 this is unresolved.
Do we need a special tool to do it?
No. The habit works with a shared plain-language document. Tools exist but are young, and the discipline is what delivers the value.
What are its older roots?
Requirements specifications (IEEE 830, from 1984), design by contract (1986), behaviour-driven development (2006) and literate programming (1984) all feed into it.
What is the main risk?
Specifications rot if not maintained, they cannot capture everything, and the practice is young and vendor-shaped, so it needs pairing with testing and review.