Spec-Driven Development
Specification-Driven Development
A development approach where a specification written before implementation guides collaboration with an AI agent.
In Simple Terms
Spec-Driven Development is an approach where you write a specification before coding, then work with AI step by step to turn it into a working program. Rather than handing AI a rough idea and letting it build freely, the spec is broken into a plan and tasks, with a human checking in at each step while an AI agent handles implementation. Since the specification stays the shared reference throughout, it's easier to prevent misunderstandings and keep the code from drifting from the original intent.
Behind the Name
The name "Spec-Driven Development" combines three English words: Specification, Driven, and Development — meaning a development process that's guided and shaped by a specification written up front, before any code is written.
Take a Closer Look!
Spec-Driven Development (SDD) means locking down a solid specification before implementation starts, then using that specification as the standard for every decision made during development.
Deriving implementation from upstream designs, like Model-Driven Development, predates AI, but Spec-Driven Development only became widespread after AI agents emerged, and what sets it apart is that it's built around AI agents at the core of the workflow.
Here, an AI agent reads a natural-language or structured specification and, with a human checking in along the way, turns it into a plan, tasks, and finally implementation.
Throughout development, the specification serves as the shared source of truth that both sides keep referring back to.
The human's job is to refine and approve the specification and verify the AI's code — handing over a spec doesn't automatically guarantee code that matches the intent.
What happens to the spec afterward depends on the project's or tool's operational model. Some keep it as the permanent source of truth, updating and regenerating the code to stay in sync with it; others treat the code as the source of truth once implementation is done, keeping the spec as a reference to return to — the right choice depends on what the project needs.
Getting the spec right up front takes some work, but it keeps communication organized and cuts down on misunderstandings and rework later.