Spec-Driven Development in 2026: The Workflow and the Tools
Spec-driven development means writing a reviewed specification before an AI agent touches code: what changes, which files it may touch, and which tests must pass. The agent implements against that contract. It emerged in 2025 as the fix for AI code that drifts from intent.
Why prompts stopped being enough
Open-ended prompting fails in predictable ways: the agent produces plausible code that drifts from what you meant, invents APIs that do not exist, and quietly rewrites things you never asked it to touch. On a small project you catch it by reading the diff. Past a certain size, nobody reads the whole diff, and the codebase decays one confident change at a time.
Spec-driven development is the industry's answer, and by 2026 it stopped being optional: GitHub, AWS, Anthropic, Cursor and Google all ship their own flavour of it. The spec is no longer documentation written after the fact — it is the input the agent executes against, and the standard the output is checked against.
The workflow, step by step
- Specify — write down what changes and why: user-visible behaviour, constraints, out-of-scope items. This is the actual engineering work now.
- Plan — the agent (or you) derives a technical plan: files to touch, order of operations, risks. Review it before any code exists.
- Task — break the plan into small, independently verifiable steps rather than one giant generated diff.
- Implement — the agent executes task by task, inside the file scope the spec allows.
- Verify — tests written from the spec gate the merge. If the suite does not fail when the feature is broken, the spec was not specific enough.
The tool landscape
The tools differ mainly in where the spec lives and how much ceremony they impose.
| Tool | Shape | Strongest fit |
|---|---|---|
| GitHub Spec Kit | Open-source CLI, 93k+ stars, works with 30+ coding agents | Teams that want a vendor-neutral standard |
| AWS Kiro | Full spec-driven IDE: requirements to user stories to steering files | Organisations standardising on one environment |
| OpenSpec | Proposal-centred change workflow with explicit delta markers | Brownfield codebases and audited change management |
| BMAD | Method and role framework layered on top of any agent | Teams that want process without switching tools |
| Native modes (Claude Code, Cursor) | Plan or spec modes built into the agent itself | Solo developers and small teams already in those tools |
Does the ceremony pay for itself?
Writing specs feels slower on day one. The payoff arrives the first time an agent implements a multi-file change and the tests pass because the spec forced you to define what passing meant. Teams that made AI coding stick in production consistently report the same three controls: a written spec per change, tests gating the pipeline, and human review of architectural decisions.
The honest counterpoint: for a throwaway prototype, a spec is overhead. The skill is knowing which mode you are in — and switching deliberately instead of letting prototype habits leak into production work.
Specs work best when you do not start from zero
A specification that says how an existing, working system must change is dramatically easier to write than one that describes a whole system from scratch. That is the quiet argument for building on open source: fork a project that already solves the adjacent problem, and your specs shrink to deltas.
The RepoLoot catalog exists for exactly that first step — 491 projects described by what they do, what you can build on top, the licence, and how hard the first deployment is, so the spec you write is about your delta, not somebody else's architecture.
Frequently asked questions
- What is spec-driven development?
- A workflow where a written, reviewed specification — behaviour, scope, constraints and acceptance tests — is produced before an AI agent writes code, and the implementation is verified against it. The spec is the input the agent executes, not documentation written afterwards.
- How is spec-driven development different from vibe coding?
- Vibe coding starts from an open-ended prompt and judges the result by feel. Spec-driven development front-loads the thinking: the spec defines what may change and what must pass before anything merges. It emerged precisely because vibe-coded output drifted from intent as projects grew.
- What are the main spec-driven development tools in 2026?
- GitHub Spec Kit (open-source CLI working with 30+ agents), AWS Kiro (a spec-driven IDE), OpenSpec (change proposals with explicit deltas, aimed at brownfield work), BMAD (a method layer), plus native plan modes in Claude Code and Cursor. They differ mainly in ceremony and where the spec lives.
- Is spec-driven development worth it for solo developers?
- Yes, in a lighter form. Even a half-page spec with an explicit file scope and a test list catches most agent drift. Reserve full ceremony for production changes; skip it consciously for throwaway prototypes rather than by default.