Spec-Driven Development: What It Solves, and What Nobody Has Solved Yet

Somewhere in 2025, the economics of software development flipped. Producing code became cheap: an agent generates a thousand plausible lines before you finish your coffee. What became expensive is ambiguity. Every assumption you don't write down is now a decision a machine makes for you, at generation speed, silently. A junior developer who misreads a ticket asks a question. A coding agent ships 800 lines that quietly violate constraints nobody stated.

Spec-driven development (SDD) is the industry's response to that flip. It is currently the most discussed methodology in AI-assisted engineering, backed by serious tooling from GitHub and AWS. Advocates call it the future of programming; critics call it waterfall in markdown. Both camps are wrong in instructive ways. This article maps what SDD actually solves, and states precisely what remains unsolved, because the unsolved part is where engineering organizations will win or lose with this approach.

Where the term comes from

Several people claim to have coined "spec-driven development." The honest formulation: no single coinage holds up. The phrase appears in academic literature as early as 2004 (Ostroff, Paige & Makalsky, XP 2004), and the term as we use it today crystallized across 2025 rather than appearing at once.

Three events did the crystallizing. In February 2025, Andrej Karpathy named the thing SDD defines itself against: vibe coding, conversational prompt-and-pray development that works for prototypes and fails for production. In June, OpenAI's Sean Grove argued at the AI Engineer World's Fair (The New Code) that our prompt habits are backwards: we keep the generated code and delete the prompt. In his words, like you "shred the source and then very carefully version control the binary". And through the second half of 2025, the tooling arrived. AWS launched Kiro in July as an agentic IDE built around specs. GitHub open-sourced Spec Kit in September. Tessl shipped the most radical interpretation, on the thesis that code should become a build artifact of the spec.

What SDD actually is, and the one distinction that matters

Strip away the tooling and SDD is one idea: make intent an explicit, reviewable, versioned artifact before generation, and keep the agent accountable to it. A spec here means a structured natural-language description of behavior, constraints, and acceptance criteria that both humans and agents consume. Nobody is writing 40-page requirements documents.

The distinction that matters more than any tool choice comes from Birgitta Böckeler's analysis of Kiro, Spec Kit, and Tessl on martinfowler.com (October 2025), which gave the field its working taxonomy:

• Spec-first: write the spec, use it to drive the task, then let it go. The code is the source of truth again afterward.
• Spec-anchored: the spec survives the task and is the artifact through which the feature evolves.
• Spec-as-source: humans edit only the spec; code is regenerated output, never hand-touched. This variant has exactly one prominent real-world attempt: Tessl, a startup that raised $125M (Fortune) on it as a founding thesis. The bet's trajectory measures the variant's maturity: the framework implementing it has stayed in beta since late 2025, and in January 2026 Tessl repositioned its public platform around agent skills instead.

Most teams practicing SDD today are on the first, some on the second. Each variant demands more discipline than the one below it, and much of the confusion in the SDD debate comes from people arguing about different variants without saying so. When someone tells you SDD failed for them, your first question should be: which variant?

Why it took off

Three forces, all downstream of the same flip.

Ambiguity became the dominant cost. GitHub's own framing when launching Spec Kit: the problem lies in our approach, in treating agents like search engines when they are literal-minded pair programmers needing unambiguous instructions (GitHub blog). Unwritten assumptions behave like debt: a spec pays them down once, up front. Without one, you pay interest on every single generation.

Decisions were rotting in chat logs. Agentic development produces decisions at unprecedented rate, and before SDD, they lived in ephemeral conversations. A spec externalizes them into something reviewable, diffable and, for organizations, auditable.

Context is the real currency of agentic engineering. A good spec is durable, structured context that survives session boundaries, model switches, and team changes. Much of SDD's value comes down to forcing teams to produce the context their agents needed all along.

Thoughtworks placed SDD in "Assess" on its Technology Radar in November 2025 (worth exploring, not yet proven) and noted in the April 2026 edition that the term suffers from semantic diffusion: it spread faster than its meaning stabilized. "Assess" is the right verdict for now. The mechanism is sound, the practice is young, and the vocabulary is still settling.

The Five SDD Questions: what any approach must answer

Having worked through the tools, the experience reports, and the failures, I find that every SDD approach, whether commercial, open source, or homegrown, stands or falls on five questions. I call them the Five SDD Questions. Their answers do more than categorize an approach: they predict where it will fail, and they locate the work no tool will do for you.

1. Persistence. What happens to the spec after the code is merged? Böckeler's variants are one possible answer space, and whether your variant is a decision or an accident defines your practice.
2. Verification. How is spec–code conformance checked rather than assumed? Natural language cannot be formally verified, and checklists interpreted by an LLM are prone to inaccuracy.
3. Evolution. How does a change request flow through the system? The candidate answers are a full re-spec, a spec delta, or regeneration. This is where "living documentation" died in the BDD era, and the failure mode is identical. In my own practice, the unglamorous answer that has held up: version each feature spec and evolve it in place, tests included. The versioning is the load-bearing part. History should show that a feature shipped against spec 1.0 and that a later data-model change bumped the spec to 1.1; edit in place without version markers and you quietly erase what the code was built against. A new spec that describes changes to another spec is a second source of truth waiting to drift.
4. Fit. At what task size and codebase age does a spec pay for itself? Writing one for a two-hour bug fix costs more than it saves, and nobody has published a defensible granularity threshold. My rule of thumb: When you would manually have to plan for a change, it's worth a spec.
5. Ownership. Who owns the spec when everyone, including the agent, can change it? In waterfall, specs drifted because nobody could update them. In SDD, everyone can, and the hard case arrives when an agent updates a spec the developer disagrees with. Somebody must own that reconciliation.

Here is the finding that should temper the enthusiasm: for questions 3, 4, and 5, no current tool ships an answer. Spec Kit's own documentation states it does not prescribe how teams preserve or mutate specs after requirements change. Verification (question 2) is getting first real attempts; Kiro's GA release introduced property-based testing that generates test cases from natural-language specs, though these attempts are early. The tools have industrialized the first mile of SDD: getting from intent to structured artifacts to code. The lifecycle after that first mile is, today, entirely the adopting team's problem.

And even that first mile is industrialized in form, not in quality. This one I learned slowly. Specs good enough to carry a feature are real work, and writing them by hand doesn't scale, so in practice agents write specs too. But an agent produces a spec exactly as good as its harness and its information sources, and building those is an engineering problem of its own. I failed at it long enough that solving it became its own open-source project.

What this means

Waterfall's return? Programming's future? Neither claim survives contact with the details. SDD rediscovers, under new economics, an old truth: intent must be made explicit. What changed is that tooling now makes explicit intent executable. The tooling is real and improving fast. The discipline it silently depends on, your team's answers to the questions the tools leave open, ships in no box you can install. Teams that adopt the tools without building that discipline will get the ceremony of SDD without its benefits, and will conclude, wrongly but understandably, that SDD failed.