How does spec-driven development work?
The flow has three steps before any code: a specification of what and why, a technical plan of how, and a task list small enough for an agent to finish one at a time. GitHub’s open-source Spec Kit structures work in that order, and Kiro writes requirements, design and tasks files for each feature (Kiro specs, read 12 November 2026). The spec is steering for the agent, not a transcript of the code. It binds interfaces, acceptance criteria and hard constraints and leaves the implementation to the coding agent.
Spec-driven development vs vibe coding vs TDD: what’s the difference?
| Vibe coding | Test-driven development | Spec-driven development | |
|---|---|---|---|
| Starts from | A prompt | A failing test | A written spec |
| Source of truth | The code | The tests | The spec, plus tests |
| Fits | Prototypes, throwaway tools | Well-understood logic | Agent-built features in a real codebase |
| Main risk | Unreviewed debt | Tests miss intent | Spec drift and overhead |
Specs and tests work together: the spec says what done means, the tests prove it.
How do we write specs our coding agents can follow?
When we deliver a sprint with agents, the spec is a gate, not a formality. We brainstorm against the client’s design document, ground every framework pattern the work depends on in current official documentation at writing time rather than from memory, and write the spec as steering: interfaces, acceptance criteria, hard constraints and pointers to the code. A read-only verifier agent then attacks the draft with the real contracts and code before a person ever reviews it. Every ticket is written as a document for an agent, because a coding agent is its reader, and each task restates a Definition of Done before implementation starts. A person approves the spec and merges the pull request; the agent does everything in between. It is the same shift as in agentic coding: the scarce work moves from typing code to stating intent precisely.