# Why Spec-Driven Development?

> The root problem SDD solves: drift, hallucination, and the limits of vibe coding. Why specs are durable artifacts that survive tool changes.

- **Source:** https://ainativesoftware.engineering/roadmap/day-5/why-spec-driven-development
- **Site:** AI-Native Software Engineering — https://ainativesoftware.engineering/book

- **Day:** 5 · position 1 of 4
- **Reading time:** 1 minute
- **Day overview:** [Day 5](https://ainativesoftware.engineering/roadmap/day-5.md)

The root problem SDD solves: drift, hallucination, and the limits of vibe coding. Why specs are durable artifacts that survive tool changes.

## Theory

**Key idea.** Spec-Driven Development (SDD) means writing a specification *before* writing code with AI. The spec becomes the single source of truth for both the human and the AI agent.


### Why SDD exists

Standard "vibe coding" often leads to broken code or regressions because the AI lacks full context. SDD uses a specification as the single source of truth, ensuring AI agents execute against a verified roadmap rather than guessing intent.


**1. Predictability and Reliability** The spec prevents the AI from straying into hallucinations or inconsistent design patterns.


**2. Efficiency at Scale** By providing AI with unambiguous, executable contracts, teams can generate working features exponentially faster.


**3. Traceability and Maintenance** The "why" behind architectural decisions is versioned alongside the code. Onboarding and auditing become significantly easier.


**4. Solving Context Drift** AI models lose project nuance over long-lived sessions. SDD forces technical constraints and success criteria to be defined upfront.


### Three levels of SDD maturity

- **Spec-First** Write specs before implementation begins
- **Spec-Anchored** Keep specs updated during evolution
- **Spec-as-Source** The spec is the primary artifact; code is generated from it


### The canonical SDD loop

`Specify → Plan → Execute → Verify → Integrate → Learn`


The core artifact set:

- **SPEC.md** Intent, constraints, acceptance criteria
- **PLAN.md** Approach, trade-offs, sequencing
- **TASKS.md** Atomic tasks with done checks

**Theory resources**

- [Understanding SDD - Martin Fowler](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)

## Practice

Run this in a repository you already know, not a toy project.

1. Take a feature you recently built (or are about to build).
2. Write a one-page SPEC.md for it: include the intent in one sentence, 3–5 constraints, and 2–3 acceptance criteria in Given/When/Then format.
3. Share the spec with an AI agent and ask it to generate a PLAN.md. Review how closely the plan matches your intent.
4. Reflect: where did the AI make assumptions you hadn't considered?

- **Previous topic:** [Harness Engineering: Everything Around the Model](https://ainativesoftware.engineering/roadmap/day-4/harness-engineering-everything-around-the-model.md)
- **Next topic:** [SDD as a Pillar of AI-Native Engineering](https://ainativesoftware.engineering/roadmap/day-5/sdd-as-a-pillar-of-ai-native-engineering.md)

---

_AI-Native Software Engineering by Alfonso Graziano (O'Reilly Media, Early Release; print edition February 2027). Every page of ainativesoftware.engineering is also served as Markdown: append `.md` to any URL. Index: https://ainativesoftware.engineering/llms.txt — whole site in one file: https://ainativesoftware.engineering/llms-full.txt._