Specification-Driven Development
Specification-Driven Development (SDD) makes a written specification the source of truth: you first describe what to build and why, then the AI derives a technical plan, a task list and finally the code from it. When requirements change, you change the spec and regenerate, instead of patching code through chat.
The typical flow
specify -> plan -> tasks -> implement
what how steps code + tests- Specify - user stories, acceptance criteria, edge cases, non-goals. No tech details.
- Plan - architecture, data model, API contracts, chosen libraries.
- Tasks - small, ordered, reviewable steps with a test for each.
- Implement - the agent works through tasks; you review each one against the spec.
What a spec looks like
## Feature: saved filters
As a user I want to save the current table filters so I can reuse them.
### Acceptance criteria
- Saving requires a name, 1-50 chars, unique per user
- Saved filters appear in a dropdown, newest first
- Applying a filter updates the URL query string
- Deleting asks for confirmation
### Out of scope
- Sharing filters between usersTools like GitHub Spec Kit and Kiro are built around this flow, but plain markdown files in the repo work too.
SDD vs Prompt-Driven Development
| Prompt-Driven | Specification-Driven | |
|---|---|---|
| Source of truth | chat prompts | spec files in the repo |
| Best for | small changes, prototypes | features, multi-step work |
| Context between sessions | lost | persisted and reviewable |
| Upfront cost | none | writing and reviewing the spec |
Why it works
LLMs fill gaps with guesses. A spec removes most gaps before any code exists, gives the agent a stable reference for long tasks, and gives reviewers something to check the code against - "does this meet criterion 3?" instead of "looks fine".
The skill shifts from writing code to writing precise requirements. A vague spec produces vague code just as reliably as a vague prompt.
updated