# What Is Spec-Driven Development?

**Short answer.** Spec-driven development (SDD) is a workflow where the
specification — not the code — is the artifact you maintain. Intent is
written and kept correct first; code is treated as something generated from
that spec and checked against it, the way a house is built from a blueprint
rather than the blueprint being redrawn afterward to match whatever got
built.

## What it inverts

The traditional loop treats the spec as a lossy prelude: you write intent in
prose, translate it by hand into code, and the moment the two diverge the
code wins by default because the code is what runs — the prose rots. SDD
flips that authority. The spec stays the artifact you evolve; the code is
its expression in one particular language and framework, regenerated and
re-verified as the spec changes.

## Why now

Natural-language specifications can now reliably generate working code,
which is what makes SDD practical rather than aspirational — a plan a
person and an AI coding agent can both act on directly. The full explanation,
including the nine-phase workflow spine Forge implements, lives on
[the spec-driven development concept page](/concepts/methodology).

## Questions people actually ask

### Does spec-driven development require a specific tool?

No — SDD is a methodology, not a product. GitHub Spec Kit, OpenSpec, and
Maistik Forge are three different implementations of the same underlying
idea: write the spec first, generate and verify code against it. What
differs between them is what happens when the agent ignores the method —
see [how Forge compares to the free alternatives](/compare/).

### How is this different from writing a PRD or a design doc first?

A PRD or design doc traditionally informs implementation and then goes
stale — it is subordinate to the code from the moment engineering starts.
SDD keeps the spec authoritative for the life of the change: code is
generated from it and re-verified against it, so the two cannot quietly
diverge without that drift being detectable.