Spec-Driven Development

SDD emerged in 2025 as the direct counter-movement to prompt-and-hope coding: agents produce plausible code that drifts from intent, invents APIs, and decays as projects scale. The proposed fix is old-fashioned and radical at once - agree on a written specification before generation, and keep it authoritative during implementation. By 2026 every major tool ecosystem ships an SDD flavor; GitHub’s Spec Kit documents the open-source workflow; support and popularity are mutable vendor facts, so evaluate the current version directly.

The movement validates something this site argues from the verification side: the missing artifact in AI coding is written intent. SDD builds that artifact at feature scale; machine-checkable specifications build it at run scale. The philosophies meet in the middle.

1. Requirements.What the feature must do, phrased as user stories with acceptance criteria - in Kiro’s flow the first of three gated phases, in Spec Kit the /specify step.
2. Design. Architecture decisions, data models, interfaces - agreed before code exists, so the agent inherits decisions instead of making them silently.
3. Tasks. The design broken into small, ordered, individually reviewable work items - the unit an agent executes.
4. Implementation against the spec. The agent codes task by task; humans review against the agreed documents rather than reconstructing intent from diffs.

Vendor and practitioner reports describe benefits in selected settings, but they do not establish a general productivity result. The secondary guide summarizes examples whose setup, attribution and measurement limits require teams to establish a dated local baseline for document effort, rework, defects and review load.

• Agents don’t reliably obey their own specs. The Fowler-team analysis notes that even with all the templates and checklists, “the agent ultimately did not follow all the instructions” - a written plan is not an enforced plan.
• Document review can exceed code review. Several practitioners report they would rather review the code than three markdown files describing it. SDD shifts effort upstream; it does not remove it.
• Specs age. A spec that is not maintained becomes confidently wrong documentation - worse than none, because it looks authoritative.
• SDD plans forward; it does not check backward. The workflow gates what gets built, but the question “does the merged code actually match the spec?” still needs an independent spec-vs-implementation check - especially given the first limit above.

SDD and Reality Graph attack the same gap from opposite ends: SDD makes the intent explicit before generation, Reality Graph verifies the result against intent after it - with boundary checks, validation the model did not author, and an evidence report per run. Teams using Spec Kit or Kiro bring excellent Solls; Reality Graph restates them as the contract a single run is measured against and closes the loop those tools leave open.