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.

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.

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.