2026-09-02

From spec to reviewed pull request: spec-driven development in practice

Why spec-driven development is the right order of things was the subject of an earlier article: first the reviewed specification, from it the architecture, from that the code. What was principle there is path here — once, concretely, from blank page to pull request.

Step 1: The spec grows as a document, not as a history

The starting point is the Spec Studio: a guided wizard that develops a project specification before a project even exists. Six content sections — vision & context, goals & non-goals, functional requirements, stack & constraints, NFRs & guardrails, epic slicing — each with an AI chat on one side and the actual text on the other. The difference from a chat history is exactly what spec-driven development is about: what grows here is a document with sections, interruptible and resumable at any time — not a conversation from which requirements would later have to be reconstructed.

Step 2: The stack becomes a contract, not a guess

In the stack step you pick one of your organisation’s profiles or start from a platform template — Spring Boot, Laravel, Angular, React/Vite, Node/Express, Go, Quarkus or Flutter — and adapt it. The profile is a contract, not a feature: language, framework, versions and check commands are stated explicitly instead of a model guessing them from the repository. Everything built later is checked against exactly these statements.

Step 3: The spec becomes tickets — and a person stays in charge

At the end you curate the epic slicing and let the studio generate: a project with repository, foundation document and the epics as real tickets in the tracker. What matters is what does not happen: no code run starts. The studio writes tickets — which story actually runs is still decided by a person, ticket by ticket. The specification sets the frame; it does not fire the starting gun itself.

Step 4: Execution follows the spec — in small, provable steps

Once a story runs, the factory works in phases and slices: requirements become a plan, the plan becomes small work steps, and every task slice is deliberately small — small enough to fit into one prompt together with its context. Every step leaves its own commit. The result is a draft pull request whose commit history is the evidence: to know whether the implementation followed the spec, you do not read a thousand-line diff but a chain of named steps.

The honest ending: reviewed means reviewable

What stands at the end is a draft, not a fait accompli. The default is that a person merges — and judging the result on its merits remains the team’s work. What spec-driven development delivers at this point is not the sign-off but its foundation: a specification you can check against, and a trail along which to do it. To walk the path yourself, the Spec Studio chapter in the documentation (in German) covers all seven steps.