Spec-Driven Development: Why AI Coding Needs a Contract in 2026

The JetBrains AI Pulse survey of 11,000 developers in January 2026 produced two numbers that sit oddly together. Ninety per cent use AI at work. Thirteen per cent use it across the entire software development lifecycle.

So AI has been adopted almost universally — as autocomplete. It suggests the next line, drafts a function, explains an unfamiliar file. What it mostly does not do is participate in how the software gets designed, built, tested and handed over.

The reason is straightforward once you have watched it happen. Coding agents will build whatever you describe, immediately, and keep building. Point one at a vague instruction and it produces a large volume of plausible code very quickly. Days later you discover it built something adjacent to what was needed. The generation was never the bottleneck. Knowing precisely what to generate is.

Spec-driven development is the practice that emerged to fix this, and in 2026 it has gone from a niche technique to something close to an industry default.

The Tooling Consolidated Fast

This is not a proposal waiting for adoption. The ecosystem arrived in under a year:

Martin Fowler has written about it. Thoughtworks published an analysis. GitHub's own framing when open-sourcing Spec Kit was that intent is now the source of truth and code is the last-mile output.

The Four-Phase Loop

Every serious SDD framework converges on the same structure, which is itself a useful signal:

The gates matter more than the phases. Each checkpoint is a place to catch a misunderstanding while it is still cheap — a paragraph to correct rather than a module to rewrite.

Writing Specs an Agent Can Actually Execute

Prose specifications fail because prose is ambiguous. EARS notation — Easy Approach to Requirements Syntax — constrains requirements into a small set of patterns that leave much less room for interpretation.

# Ubiquitous — always true
shall

# Event-driven
When
shall


# State-driven
While
shall

# Unwanted behaviour
If
thenshall


# Optional feature
Where
shall

Compare that to "handle payment failures gracefully" — which is what most tickets actually say, and which an agent will interpret in one of about nine reasonable ways.

Is This Just Waterfall Again?

It is the obvious objection and it deserves a straight answer rather than a dismissal. The critique has been raised repeatedly — on Hacker News, in the Thoughtworks analysis, by plenty of engineers who lived through the original.

The surface resemblance is real. Write the requirements first. Design before building. Gates between phases. That is recognisably waterfall.

What changed is the cost of being wrong. Waterfall failed because specifications were expensive to produce and ruinous to revise — months of analysis, and by the time reality contradicted the document, the political cost of changing it exceeded the cost of shipping the wrong thing.

Rewriting a spec now takes an afternoon. Regenerating the implementation from the revised spec takes hours. When iteration is that cheap, the argument against specifying upfront mostly evaporates — you are not committing to a plan, you are writing down the current one somewhere an agent can read it.

When to Use It, and When Not To

The pattern most teams settle on is sequential rather than exclusive: vibe-code a spike to learn the shape of the problem, distil what you learned into a spec, then spec-drive the version that ships. The prototype was never wasted — it was the research phase.

The Part Nobody Writes About: Handover

Most SDD discussion frames the benefit as code quality. There is a second benefit that matters more in some situations and is rarely mentioned.

When an AI agent builds a system through unstructured prompting, the intent behind every decision lives in a chat transcript. Why is retry logic three attempts and not five? Why does this service own that table? The code shows what, never why.

Six months later — new engineer, or a client taking over a codebase an agency built — that context is simply gone. The code is readable and the reasoning is not. Changes get made nervously, or not at all.

A spec in version control is the artefact that survives. It records the decisions, the constraints, the edge cases that were considered and rejected. For anyone who builds software that someone else will own, the spec is not project overhead. It is the deliverable that makes the code usable after you leave.

Adopting It Without a Six-Week Rollout

Frequently Asked Questions