Spec-Driven Development

Spec-Driven Development (SDD) is the practice of making an AI coding agent write down what it is about to build, and getting agreement on that, before it builds anything. The pitch is a direct response to how agentic coding actually fails: requirements that live only in a chat transcript cannot be reviewed, cannot be diffed, and cannot be held to — so the agent drifts, and the drift is only visible once the code is wrong. SDD moves the agreement into files in the repository, where a human reviews a plan instead of auditing a diff.

• The requirements/design/tasks trio - All three major implementations emit substantially the same artifacts: requirements or a proposal, a technical design, and a sequenced task list. Kiro writes requirements.md, design.md and tasks.md; Spec Kit scaffolds the same shape under .specify/; OpenSpec puts a proposal, design, tasks and requirement deltas in a change folder under openspec/.
• A review gate before code, not after - The reviewable unit moves from the pull request to the plan. This is the actual claim of the practice, and the one worth testing.
• Requirements written as scenarios - OpenSpec uses SHALL statements with WHEN/THEN scenarios; Kiro uses user stories with acceptance criteria. Both are BDD’s Given/When/Then, relocated out of the test suite and pointed at an agent rather than a test runner.
• Standing project context, separately - Each keeps long-lived guidance apart from per-feature specs — Spec Kit in a constitution, Kiro in .kiro/steering/. That layer is the same job AGENTS.md does.

The convergence is real and the interoperability is nil. Three toolkits agreed within months on roughly what documents a feature needs, and agreed on nothing else: no shared grammar for a requirement, no shared directory, no schema, no conformance notion, and no way to hand one toolkit’s specs to another. There is no specification of spec-driven development — only three vendors’ conventions, each of which can move with a release. A team adopting SDD today is adopting a vendor, and in Kiro’s case a proprietary product and a billing relationship with it.

It is worth separating this from the older idea it borrows its name from. API-first — writing the OpenAPI contract before the implementation, so that consumers, mocks and tests can be built against it — has been the practice in API teams for over a decade, and its artifact is a machine-readable contract that tooling validates and generates from. SDD’s artifacts are prose Markdown for a language model to read. The two share an instinct, that agreeing the interface before building it is cheaper than discovering it afterward, but they differ on the thing that matters most to this catalog: API-first produces an artifact a machine can check, and SDD, so far, does not.

That gap is the interesting question. Every one of these toolkits describes requirements in structured-but-unvalidated Markdown, at exactly the moment the industry has a mature stack for saying what a thing is in a way a machine can verify. Whether SDD converges on something checkable — a schema for a requirement, a linter, a conformance suite — or stays a set of house styles that each vendor evolves alone, is what will decide whether it is a methodology worth cataloguing in five years or a moment in tooling history.