What it is
Spec-Driven Development (SDD) flips the usual hierarchy: the spec doesn't serve the code — the code serves the spec. You start with a detailed spec (a contract for how the system should behave), and it becomes the source of truth agents use to generate, test and validate code. The spec is a living, executable artifact, not an after-the-fact document.
Where it came from
- September 2, 2025 — GitHub announced Spec Kit, an open-source SDD toolkit, framed explicitly as an "antidote to chaotic vibe-coding".
- The core loop:
Specify → Plan → Tasks → Implement(describe the what and why → plan for your stack → break into verifiable tasks → build). - In parallel, the same "spec as contract" idea was pushed by methodologies like the Quest pipeline (EARS requirements + design → plan → execution with verification).
Why it took off
- Pure vibes don't scale: production needs an artifact both a human and an agent can check.
- A spec gives the agent a frame — far less improvisation, and much easier review (you look at changes relative to the contract).
- Support out of the box: Spec Kit works with 30+ agents (Claude Code, Copilot, Gemini CLI, Cursor, Codex), and the repo quickly passed ★90k.
How to use it today
- Before a big feature, write a short spec: goal, behavior, acceptance criteria (instead of jumping straight to "write the code").
- Run the Spec → Plan → Tasks → Implement loop; review at every handoff.
- Keep the spec in the repo next to the code — update it first when requirements change.
What to watch out for
- For a small fix, SDD is overkill; save it for non-trivial work.
- A spec without verification is just text; the value is that verifiable tasks and tests come out of it.
- Watch for "specs for the sake of specs": keep it executable (acceptance criteria → tests), otherwise it goes stale.