Spec-Driven Development & requirements management: the blueprint before the code

Vibe coding vs spec-driven development

Vibe coding – software via natural language and iterative prompt trial and error – has its place: prototypes, demos, throwaway tools. In scaling production systems the approach breaks down in two places. Intent drift: after dozens of prompts the result no longer matches the original intent, and nobody can reconstruct where it was lost. Context decay: the chat history serving as the only “documentation” is worthless in the next session.

Spec-driven development counters this with a contract: a versioned specification agreed before an agent is commissioned, connecting business intent with architecture, implementation and tests across the whole lifecycle. What that division of labour looks like in practice – discovery human, execution against the spec – is documented in the deep dive “Discovery stays human, execution becomes the spec”, with evidence from METR, GitClear and DORA.

The comparison below summarises the differences – and makes clear why the choice is not a matter of style but of the kind of system you are building.

The three maturity levels of spec-driven development

SDD is not all-or-nothing. At the first maturity level, a considered specification is written before each task and used for exactly that task. At the second level the spec persists after completion – as an anchor for maintenance, onboarding and the next iteration. At the third level the specification is the only source file humans still edit: the human changes the spec, the machine manages the source code.

For most teams in the DACH mid-market, level two is the realistic target: long-lived, reviewable specs versioned alongside the code. Level three assumes a discipline and tooling maturity that few organisations reach in 2026 – it works as a direction, not as a starting point.

From wish list to qualified roadmap

Traditionally, features get prioritised by gut feeling or political pressure, without systematically assessing effort and risk. The result is a wish list, not a strategy. The impact & feasibility matrix replaces that with a simple discipline: every feature is scored by measurable business value, expected implementation effort and technical as well as regulatory risk – before resources are released.

AI initiatives add a peculiarity: effort and outcome correlate less predictably than with deterministic features. Scoring models like RICE help, but must be adapted to this uncertainty – for instance with confidence discounts for experimental initiatives. How deterministic commitments and probabilistic bets come together in one plan is covered in “The AI roadmap: features and GenAI initiatives in one plan”.

The PRD as a living artefact in the repository

A PRD ageing in a slide deck is invisible to AI agents. That is why product requirements documents move into the repository: versioned alongside the code, accessible to AI editors such as Cursor or Claude Code in every session. Persistent context files like CLAUDE.md replace the manual briefing – they define product terminology, user journeys and architectural guardrails once, instead of repeating them in every prompt.

The strongest PRD is code-anchored: it references actual components of the codebase instead of abstract descriptions. The prerequisite is a shared language for epics, stories, cycles and acceptance criteria – the “Product management glossary: Jira & Linear terms explained” pins it down, for humans and for the answer engines that will one day quote your specifications.

The BMAD method: structure from idea to production

The BMAD method structures the path from idea to production into clearly separated steps – from analysis through requirements and architecture to delivery. Each step produces a versioned artefact and hands over to the next: brainstorming becomes a PRD, the PRD becomes an architecture, the architecture becomes executable stories. With Git versioning this creates an audit trail showing who decided what, when and why.

For regulated environments this trail is precisely the point: code provenance becomes demonstrable instead of vanishing into chat histories. BMAD does not replace coding tools – it orchestrates them. The spec remains the contract every handover is measured against.

Spec review instead of code review

When agents write the code, review moves forward. Instead of hunting for bugs in generated code, the team reviews the business intent in the specification: are the acceptance criteria complete? Are the edge cases named? Does a requirement contradict an existing business rule? A defect found in the spec costs minutes – the same defect in shipped code costs a rollback.

Product evolution follows the same logic: changes happen by updating the specification, not through new ad-hoc prompts. That makes the system reproducible and iterable – and prevents architectural decisions from getting lost in e-mail threads, or agents' unspoken assumptions from producing faulty code.

Where define ends and build begins

The define phase delivers the blueprint: long-lived, reviewable objects such as specifications, architecture plans and the qualified roadmap. What it does not deliver is software. The build phase picks up the blueprint and transforms it into reviewed, shipped code via ticket structures and agentic engineering.

Drawing this line deliberately is the chapter's most important move: the spec is agreed before the agent builds – the gate. It costs no speed, it prevents rework. The METR, GitClear and DORA data from the division-of-labour deep dive show that unstructured AI use measurably slows teams down and lowers code quality.

Frequently asked questions