Request a demo
← Insights Engineering

Spec-driven development: who checks the spec?

Spec-driven development moves the human's job from reviewing code to reviewing the spec. That review is now the step everything else rests on, and it is four different checks, not one.

AgileAI Labs · 14 November 2026 · 10 min read

What spec-driven development is

Spec-driven development means writing a specification before an AI agent writes code, and treating that specification as the source of truth for both the person and the agent. That is the working definition Birgitta Böckeler arrived at on martinfowler.com in October 2025, with the caveat that the term was still unsettled.

GitHub gave the practice its most visible form in September 2025 with Spec Kit, an open-source toolkit built around four phases: specify, plan, tasks, implement. Its launch post describes the change as moving the source of truth from code to intent. Thoughtworks placed the technique in the Assess ring of its Technology Radar in November 2025, and placed Spec Kit itself in Assess in April 2026.

The reasoning is sound. A coding agent handed a vague request has to guess at everything left unsaid. GitHub's post makes the point directly: some of those guesses will be wrong, and the errors tend to surface late. A written spec leaves less to guess.

The method moves the review. It does not remove it.

Read the launch post closely and one instruction repeats at every phase: verify. Confirm the spec captures what you actually want. Confirm the plan accounts for real constraints. Look for the gaps and edge cases the agent missed before moving on.

That is a real change in where human attention goes. In ordinary AI-assisted coding, a person reviews code. In spec-driven development, a person reviews the spec, and the code is checked against it. If the spec is wrong, the agent builds the wrong thing faithfully, and every later check confirms it.

Spec-driven development does not ask you to trust the agent. It asks you to trust the spec, and then holds the agent to it.

What reviewers actually face

The published first-hand accounts are consistent about one thing: the specs are long. Böckeler reports that one tool expanded a small bug fix into four user stories and sixteen acceptance criteria, and that another produced so many repetitive Markdown files that she would rather have reviewed code. The Thoughtworks Radar notes that some tools generate lengthy spec files that are hard to review, and that teams using Spec Kit reported verbose Markdown adding to cognitive load.

None of this is an argument against the method. It describes the review the method depends on: long documents, drafted quickly by a model, read by a person under the same time pressure that made vague tickets common in the first place.

“Checking the spec” is four different checks

When a team says the spec was reviewed, it can mean any of four things. They are not equally easy, and they are not interchangeable.

1. Is it well formed?

Structure and phrasing. Kiro writes requirements in EARS notation: when a condition occurs, the system shall respond in a stated way. Spec Kit ships templates. Tools handle this well. It is the cheapest check and the least informative, because a perfectly phrased requirement can still be wrong.

2. Is it consistent with itself?

Ambiguity, contradiction and gaps inside the document. Tools have started to automate this. Kiro's documentation describes an Analyze Requirements step, run before design, that checks for logical inconsistencies, ambiguities, conflicting constraints and gaps. Spec Kit's documentation lists quality checklists and cross-artifact analysis.

3. Is it consistent with what was already decided?

A spec is written for one change. The organization decided things last quarter, for another team's feature: what an active account is, how fast search has to be, who can approve a refund. A new spec that contradicts one of those decisions can be internally flawless. Catching it takes a record of decisions that outlives the change it was made for.

4. Is it what the business meant?

A tool can flag “results load fast” as unmeasurable. Only a person with the authority to decide can say two seconds on mobile. The question has to reach that person, and the answer has to be kept with a name and a date. Otherwise it is asked again next sprint, or answered differently by someone else.

The first two checks are about the text. The second two are about the organization. A team can pass the first two on every spec and still ship software that contradicts a decision nobody remembered making.

Why the last two matter more with agents

Boehm and Basili named hastily specified requirements as a major source of avoidable rework, and put avoidable rework at 40 to 50 percent of project effort. That was 2001, when a developer who hit an ambiguity usually stopped to ask.

The Thoughtworks teams working with Spec Kit on existing systems reported the same pattern in 2026 terms: most rework came from unclear intent, unstated assumptions and constraints discovered late. An agent does not stop to ask. It fills the gap with a plausible default and keeps going.

Meanwhile the check on the code side is thin. In Sonar's January 2026 survey of more than 1,100 developers, 96 percent said they do not fully trust AI-generated code to be functionally correct, and fewer than half said they always check it before committing. When the code is checked less, the spec carries more of the weight.

Five questions to ask before an agent builds from a spec

  1. Does every requirement state an outcome that a specific observation could prove false?
  2. For each vague word that became a number, who chose the number?
  3. Does anything here contradict a decision already made for another feature or another team?
  4. Which questions are still open, and who owns each one?
  5. Does a test trace back to each requirement?

A spec that cannot answer the second and third questions has been checked as a document. It has not been checked as a decision.

Where Spec2TestAI acts

Requirements Intelligence scores each story and its acceptance criteria on 32 quality measures before it reaches a developer or an agent. What a requirement leaves open becomes a question for the people who can answer it. Each answer is kept in the project knowledge base as a decision, with who decided and when, and informs later requirements in the same project. That record is what we call Specification Intelligence.

Spec2Code AI then delivers the approved requirement, your standards and your security policy into GitHub Copilot, Cursor, Windsurf, Cline and Claude over MCP. This sits upstream of a spec-driven workflow: the spec an agent plans from starts with requirements that have been questioned and decided.

What this does not solve

It does not replace the planning and task steps that spec-driven tools provide, or the review of plans and code. Those are different checks, and they still need doing.

A recorded decision can still be a wrong decision. The record makes it visible and attributable. It does not make it correct.

We have not run a controlled comparison of spec-driven workflows with and without requirement scoring, and we are not aware of a published one. The claim here is narrower: the review this method relies on is four checks, and two of them need a person and a record.

Sources

Get your backlog scored

Send one backlog. We score it on 32 measures, find the conflicts across the stories, and list the questions nobody has answered yet. Fixed fee.

See the Quality Risk Audit