Spec-driven development is having its biggest moment at the exact instant its foundation gives out. Let me say the point plainly before the nuance: SDD was built on the assumption that building software is expensive, so you de-risk it up front — and AI has erased that assumption. The practice isn't useless. But the reason most of us reached for it no longer holds, and that should change how you write every spec.
IThe assumption isn't wrong — it's dead
If you've watched developer tooling this year, you've felt the wave. GitHub's open-source Spec Kit has become one of the fastest-growing dev-tools repos going, with 90,000+ stars, 8,000+ forks, and support for 29+ coding agents — Claude Code, Copilot, Cursor, Gemini CLI, Codex CLI, the lot. AWS shipped Kiro, a whole IDE built around specs. IBM adapted the approach for infrastructure. This is a genuine, still-maturing industry pattern, not one company's toolkit.
Now the awkward part. The reason spec-driven development exists — write the plan first, because writing the code is the expensive, risky bit — is the exact assumption that just collapsed. The line that kicked this essay off came across my watchlist in June 2026, when Lenny Rachitsky summarized Andrew Ambrosino, who leads product and engineering on OpenAI's Codex: "The old product process was built around the assumption that building things is expensive, so de-risk everything up front with specs, research, and prototypes. That assumption is gone." When the premise under a practice dies, the practice doesn't automatically die with it. But you can no longer run it on autopilot. You have to ask what it's actually for.
IIWhy "de-risk everything up front" used to be the only sane move
For about thirty years this wasn't a philosophy, it was arithmetic. Engineer time was the scarcest, most expensive input in the building, and code was hard to reverse once written. A single feature could be a week or two of a senior engineer's time, plus review, plus the cost of tearing it out if it turned out to be the wrong feature. Against that, a spec is nearly free. So you measured twice and cut once — requirements, edge-case research, a throwaway prototype to test the risky assumption. All cheap hedges against an expensive mistake. Waterfall earned its bad name, but the instinct underneath it was rational for its economics: iterate on the plan, because iterating on the code is what costs you.
That instinct is stamped into every current spec-driven tool. GitHub frames Spec Kit as a shift from "code is the source of truth" to "intent is the source of truth" — write the spec, treat it as the durable artifact, generate the code beneath it. It's a genuinely smart answer to a real failure mode: coding agents that confabulate whole features when you hand them a vague prompt. GitHub says as much, positioning Spec Kit against "vibe coding" and telling you to treat a coding agent like a "literal-minded pair programmer" instead of a search engine. But notice the load-bearing assumption underneath all of it — that a wrong turn in code is costly enough to be worth preventing with pages of prose. That was true. The question is whether it still is.
IIIWhat changed: building got (almost) free
Here's the reversal in Ambrosino's own words, from Lenny's Podcast in June 2026: implementation used to be expensive, so "before writing code, you had to do a lot of upfront risk mitigation — writing documentation, conducting research, prototyping." And then: "now that assumption has completely reversed." The new bottleneck, he argues, is taste — curation and judgment, not building.
It's not just talk. Codex started life as a developer tool that was, in his telling, almost hostile to non-engineers; today nearly all of OpenAI's own staff use it weekly, not just the engineers. The numbers around cheap building have gone mainstream fast:
None of this means the code is good — hold that thought for two sections. It means the raw act of producing a working feature has fallen from "days of a salaried engineer" to a few dollars and a few minutes. When the thing you were insuring against gets orders of magnitude cheaper, the premium you pay for it — long specs, up-front research, prototype gates — starts to look expensive relative to what it actually protects.
IVSDD's own definition is already splitting in two
If a practice's foundations were solid, its proponents would agree on what it is. They don't. Thoughtworks' Birgitta Böckeler, writing on Martin Fowler's site in October 2025, split spec-driven development into three levels, and the differences aren't cosmetic:
- Spec-first: the spec guides the AI, but the code stays primary — you can toss the spec afterward.
- Spec-anchored: the spec persists as a living, synchronized contract that governs the code over time.
- Spec-as-source: the spec is the real source, and the code is a disposable byproduct you regenerate — humans may never touch it.
GitHub's "intent is the source of truth" sits toward the anchored end. Tools like Tessl push all the way to spec-as-source; Kiro lands somewhere in the middle. That's an enormous spread hiding under one buzzword. Is the spec a scratch pad, a contract, or the program itself? The honest answer is the industry hasn't decided — and it matters, because your answer determines whether a spec is worth a paragraph or a week. The sharpest criticism lands on the spec-as-source end, where the whole bet is that you can describe a system completely enough that nobody ever needs to read the code.
VKent Beck's objection: specs assume you won't learn anything by building
The cleanest critique comes from Kent Beck, who has been shipping software longer than most of the people writing spec tools have been alive. Quoted in Fowler's January 2026 fragments, Beck's objection is one sentence and it's devastating: spec-driven development, as usually described, "encodes the (to me bizarre) assumption that you aren't going to learn anything during implementation that would change the specification."
That's the tell. Writing the whole spec before you build is waterfall in a new outfit — it only pays off if building teaches you nothing. But building always teaches you something, and now that building is cheap, building is often the fastest way to learn. Beck sharpens it with two games. In what he calls "The Finish Line Game," you ship once and a great spec can get you there. In "The Compounding Game" — the one most real products are actually playing — you ship over and over, and "a better spec will never get you from $N to $N+1 forever." Compounding, he argues, needs as much investment in futures as in features. Fowler lands in the same place: the real prize with AI isn't a better plan, it's accelerating the feedback loops — the core value of Extreme Programming, now on fast-forward. If iteration is where the value is, a spec that freezes your understanding before you've iterated once is working against you.
VIThe data that complicates both sides
I don't want to trade one flavor of hype for another, so here's the tension honestly. "Building is cheap" is not the same claim as "building is fast" or "building is safe," and the data pulls those three apart.
On speed: METR ran a randomized controlled trial with experienced open-source developers on large, mature codebases — and the AI tools made them slower, not faster. Their February 2026 follow-up walked the headline back toward roughly neutral after correcting for who kept volunteering, but "neutral" still isn't the productivity miracle the demos promise. On safety: Veracode tested more than 100 models and found AI-generated code shipped a serious vulnerability nearly half the time. The picture:
That 45% figure has barely moved even as the models got dramatically better at writing code that compiles. Syntactic quality went up; security stayed flat. Cheap code, in other words, is emphatically not de-risked code — and that is exactly the technical debt AI leaves behind. It's fast to accept and slow to discover. So the anti-spec crowd doesn't get to declare victory either: building is cheap, but cheap building is neither reliably fast nor safe.
VIISo what's actually scarce now? Taste.
Put those two facts together and you arrive at Ambrosino's real point, which is subtler than "AI writes the code now." The scarce resource moved. It used to be implementation. Now it's judgment — deciding what deserves to exist, and checking hard what got built. Taste and curation are the bottleneck.
This is the thread I keep pulling on, because I watch it happen every day. I've written before about the reviewer, not the builder, became the coveted role and about the week output got free and judgment got expensive — the same phenomenon from two angles. When a machine can produce ten plausible versions of a feature for a few dollars, the person who can tell the good one from the confident-but-wrong one is worth more than the person who can produce another ten. Specs don't die in that world. Their job changes — from de-risking the build to encoding the judgment about what's worth building and what "good" looks like.
VIIIWhat this looks like in practice, from someone who runs a live agent swarm daily
I run a production swarm of AI agents most days — it's how the studio actually delivers work — and I still write specs. I just don't write them the way the tutorials tell you to. Here's the honest version.
The specs that earn their keep are short. A page of intent — what we're building, for whom, what "done" looks like, and the two or three constraints that must not break — steers an agent far better than a thirty-page requirements doc, because a literal-minded agent will follow a compass and drown in a contract. I laid out the mechanics in my honest verdict on letting a system prompt your agents for you, and the pattern holds here: the doc's job is direction, not a cage.
And specs genuinely shine for handoff and memory. A practitioner named Roger Wong documented building a transit app spec-first — roughly 6,000 lines across eight features, about three days from spec to deploy — then came back two weeks later and added features without re-learning the codebase, because the spec still explained the why. That's the good case: the spec as durable memory, not an upfront gate.
Where it curdles into theater is when the spec becomes a substitute for building — pages of anticipated edge cases for a feature you could have stood up in an afternoon and actually looked at. When building was expensive, that caution was rational. Now it's often slower than just building the thing and reviewing it hard. (For the orchestration side of that — running it without a big platform — here's how I run a production agent swarm without a platform.)
So the takeaway isn't "spec-driven development is dead." It's this: write specs like a compass, not a contract. Enough to point the work in the right direction and to remember why later — and no more, because the expensive part isn't building anymore. It's knowing what's worth building, and being able to tell when the machine got it wrong.
— Michael Rouveure
