What Is Spec-Driven Development?

The Problem: Vibe Coding

The way most people use AI to build software looks like this: type "make me a login page," see what comes out, type "no, add a remember-me box," and keep nudging. People call this vibe coding - you steer by feel, turn by turn. It's fast and fun for a demo, and it falls apart on anything real.

Why it falls apart: the AI is constantly guessing what you meant, and you only find out it guessed wrong after it's built the wrong thing.

The Fix: Spec-Driven Development

Spec-Driven Development (SDD) flips the order. Instead of jumping to code, you first write a clear specification - what to build, for whom, and what "done" means. Then the agent generates the code from that spec. The spec becomes the primary artifact; the code is just its output.

An Analogy: Blueprints Before Bricks

Nobody builds a house by telling builders "just start laying bricks and I'll tell you when it looks wrong." You draw blueprints first - rooms, dimensions, where the plumbing goes - get them approved, and then build. Changing a line on the blueprint is cheap; knocking down a built wall is expensive.

The Core Loop: Spec → Plan → Tasks → Implement

Most SDD methods share the same four-step shape. You and the AI move through it together, with you approving each step before the next:

1. SPEC       Describe WHAT to build and what "done" means.
              (the requirements - no code yet)

2. PLAN       Turn the spec into a technical approach.
              (architecture, tech choices, how it fits together)

3. TASKS      Break the plan into small, testable pieces of work.
              (each one a clear, checkable chunk)

4. IMPLEMENT  The agent builds each task, checked against the spec.
              (code, finally - and it traces back to the spec)

Each step produces a written document that feeds the next. You review at every arrow. The agent never runs ahead and builds on a guess.

The "Constitution": Rules That Govern Everything

Most serious SDD setups start with a constitution (sometimes a CLAUDE.md-style file): a short set of governing principles that everyspec, plan, and task must obey. Think of it as the project's house rules.

# Project Constitution (example)

- Language: TypeScript. No new languages without approval.
- Every feature ships with tests. No exceptions.
- Accessibility: all UI must be keyboard-navigable.
- No secrets in code; use environment variables.
- Prefer boring, well-known libraries over clever new ones.

How This Level Builds Up

SDD is a family of methods. We'll go from the shared foundation to the two biggest named systems:

74  Writing specs that don't lie  - EARS notation, FRs vs NFRs
75  The SDD toolbox              - Spec Kit, Kiro, OpenSpec, Tessl
76  BMAD, part 1                 - the AI "product team" of agents
77  BMAD, part 2                 - the full workflow, step by step
78  BMAD, part 3                 - build a real small app with it
79  LID                          - Linked Intent Development, the "arrow"
80  Best practices & anti-patterns - when SDD helps, when it's overkill

Hands-On: Catch an Intent Gap