Home / Spec-driven development
📐 The definitive guide

What is spec-driven development?

A development methodology where every feature is specified, reviewed, and approved as a written artifact before code is generated — turning AI-assisted work into something reviewable, revertible, and maintainable.

Definition

Spec-driven development is a software practice in which a feature progresses through gated stages — a PRD, an architecture doc, a plan, then the build — and each stage produces an approved, version-controlled specification that the next stage must build on. The spec, not the chat history, is the source of truth.

Why it matters

Vibe coding feels fast. Spec-driven development stays fast.

Prompting for code with no plan is quick — until the third change breaks the second one. A spec keeps the velocity and adds a spine.

Without a spec

Vibe coding

One long chat. Decisions live in your head and scroll away.

!No shared spec. Why anything was built is lost in chat history.
!Unbounded scope. The model rewrites whatever it touches.
!No record of approval. Nothing is reviewable or revertible by intent.
!Drift compounds. Rework grows with the codebase.
Spec-driven development

A gated pipeline

Every stage is written down and approved before the next begins.

Git-tracked markdown. PRD, architecture and plan live in the repo.
Phased, scored tasks. Work breaks into Fibonacci-scored steps ≤3.
Gates enforced in code. No stage advances until the prior is approved.
A visible board. The whole pipeline on localhost, always current.
In practice

How SpecManager embodies spec-driven development

SpecManager implements the methodology as six gated stages. Each produces an approved markdown artifact committed to git before the next can begin.

01
PRD
The problem, users and success metrics — written and reviewed.
gate ✓
02
Architecture
Affected components, data flow, interfaces. PRD-grounded.
gate ✓
03
Design
Optional high-fi screens for UI-bearing work.
optional
04
Plan
Phased, Fibonacci-scored tasks ≤3, emitted as records.
gate ✓
05
Build
One phase at a time. Stops at every phase boundary.
gate ✓
06
Walkthrough
Per-phase and feature-level docs of what shipped.
gate ✓

The gates are enforced in shared code, not in a prompt — the builder physically cannot advance a feature past an unapproved stage. Approvals are yours to give, and every artifact is plain markdown committed to your repo. This is the difference between a methodology you intend to follow and one your tooling guarantees.

Key takeaway

Spec-driven development replaces ad-hoc prompting with a sequence of approved, version-controlled specifications. For Claude Code, SpecManager enforces this as a six-stage gated pipeline — PRD, architecture, plan, build — so AI moves fast without producing code no one can review or maintain.

Common questions

Spec-driven development, answered

Is spec-driven development the same as waterfall?

No. Specs are written per feature and approved in small phases, not for the whole product up front. You keep iterative delivery — each feature flows through the pipeline independently and ships when its phase is done.

Does it slow AI coding down?

The approval gates add minutes, not days. In exchange you remove the compounding rework that unstructured “vibe coding” creates once a codebase grows past a few features.

What does a spec actually contain?

A PRD (problem, users, goals, success metrics), an architecture doc (components, data, interfaces), and a plan (phased, scored tasks). All are git-tracked markdown — reviewable and revertible by intent.

Your next feature deserves a spec.

Bring structure to your AI workflow without losing the speed that made it worth using.