Spec driven development: who checks at the end?

I cloned GitHub's Spec Kit repository and counted the prose in the nine commands it installs, sorting each one by a single question: is this instruction read before or after the code exists? The count took less time than writing this paragraph, and the asymmetry came out cleaner than I expected to find in anything from the real world.

There are 13,647 words of instruction before a single line of code, against 1,764 after. In numbered steps the distance is the same: 830 before and 67 after.

Command	When it runs	Words	Steps
constitution	before	1,386	69
specify	before	2,436	152
clarify	before	2,658	165
plan	before	1,065	59
tasks	before	1,594	103
analyze	before	1,546	81
checklist	before	2,962	201
implement	writing	1,671	114
converge	after	1,764	67

The count is easy to repeat and worth repeating: the prompts live in templates/commands/ in the github/spec-kit repository, one markdown file per command, and what I counted was body words after the frontmatter plus any line starting with a number or a bullet. The classification of each command is not my opinion, because it is written into the prompt itself, and I come back to that further down.

Spec Kit is the best case, and it is still seven to one

Spec driven development has at least two large lineages today, and the Spec Kit one takes the question in the title more seriously than the other, because it is the only one that installs a command whose job is to check delivered code against the specification.

The other lineage came out of RPI, short for research, plan and implement, which left HumanLayer in 2024 and was picked up by tools like Goose. In 2026 its own author retired the method and published the successor, CRISPY, with seven stages: questions, research, design, structure, plan, work, pull request. Alongside it, another author published QRSPI, with five.

Neither successor has a checking stage, and that is not me reading between the lines: the CRISPY documentation describes no dedicated verification stage, and the QRSPI one says it focuses on upstream improvements rather than downstream validation.

The five new RPI stages all landed before the code

Look at what was added when RPI grew. Questions, design and structure in HumanLayer's version; questioning and structure in the other. Five new stages in two years, and every one of them happens before a line of code exists, which makes sense, because the problems they solve also happen before.

HumanLayer documented those problems with a candour that is rare and worth recording: the research mixed objectives with implementation detail and lost its objectivity, the alignment steps were skipped probabilistically, and engineers ended up reviewing thousand-line plans that frequently diverged from the implementation that came out the other side. They also tell of six months spent not reading the generated code, after which they had to rip out and rebuild large parts of the system.

The instruction budget is finite, and HumanLayer measured it

The part that ties it together is a measurement HumanLayer published themselves: frontier models reliably follow between 150 and 200 instructions, and the RPI planning prompt alone held 85, so that adding the system prompt and the tool definitions the teams blew past the budget before starting, and half the time the model skipped straight to writing the complete plan, without the alignment conversation that was the entire point of the stage.

Put the two measurements side by side and an uncomfortable conclusion falls out. Every stage added before the code competes for the same finite budget, so that fixing an upstream failure by adding an upstream stage spends precisely the budget the skipped step needed. RPI blew the limit with three phases. The response was to publish a version with seven.

It is not that the remedy is wrong; it is that it is served in the glass that was already full.

What GitHub documents and almost nobody quotes

Back to the classification of those nine commands, which I said was not my opinion. The converge prompt says it must run only after implement. And the checklist prompt, the longest of them all at 2,962 words, states in bold what it does not do:

❌ NOT checking if code/implementation matches the spec

And it explains, with an image I find excellent: if your specification is code written in English, the checklist is its unit test suite, and you are testing whether the requirements are well written, complete and unambiguous, not whether the implementation works.

The tool separates the two things in plain sight. The public conversation about the method, which measures the cost of ceremony and argues about how many files to keep, almost never separates them.

Why convergence is the cheapest stage

Convergence, which is what Spec Kit calls checking delivered code against the specification and what Microsoft calls validate in its own cycle, has a property no upstream stage has: it runs afterwards, in a fresh context, with the code already written in front of it.

It does not compete for the planning budget, because it is not in the same window. It does not have to anticipate what will go wrong, because whatever went wrong is already on disk. And the artifact it compares against is not a prediction, it is a file.

For the 1,764 words it costs in Spec Kit, it is the cheapest stage in the whole method, and it is precisely the one the two most discussed methodologies in the field do not have.

What you can measure in your own process

The question this count leaves behind is easy to repeat in any tool, including the homemade ones. Take your process, list the stages, and sort each one by the same question: is it read before or after the code exists? Then add up the prose on each side.

If the ratio looks like seven to one, you are at the field average. If there is nothing at all on the after side, you have a method that writes a promise and never collects on it, and the difference between the two shows up on exactly the day the specification turns out to be wrong.

Sources

The numbers in this text come from here, and the first two can be checked in minutes:

• The prompt count is mine, done on 2026-09-11 over github/spec-kit, directory templates/commands/.
• The 150 to 200 instruction ceiling, the RPI failure modes and the move to CRISPY: HumanLayer, via ZenML.
• The parallel evolution into QRSPI: betterquestions.ai.
• Microsoft's seven-step cycle, ending in validate: developer.microsoft.com.
• Sanderson Oliveira de Macedo. From Prompt to Process: a Process Taxonomy and Comparative Assessment of Frameworks Supporting AI Software Development Agents. arXiv:2606.04967 — compares seven frameworks and finds divergence in process with convergence on acceptance criteria, test scenarios and context.