H
Howardism
Plate IIAI Coding PracticeHOWARDISM

Spec-Driven Development as the New Waterfall

Robert C. Martin reads the 2026 spec-driven-development movement as the 1970s big-design-up-front temptation returning under new branding, and reports his own attempts failing the same way: the plan cannot anticipate what the agents hit, so the human stops them, rewrites, restarts — his answer is the agile one (a story or two, then look at the architecture), justified by the cost of change falling near zero, with specs kept ephemeral and never committed because the finished artifact is the specification

Article metadata
Publication details
Published:September 1, 2026
Filed:Concept
Domain:AI Coding Practice
Tags:AI Coding WorkflowPlanningAgile
Reading:11 min
Source:AI-synthesised
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Illustration for Spec-Driven Development as the New Waterfall

Sources#

Summary#

Robert C. Martin (Uncle Bob on Software Fundamentals in the Age of AI, 2026-08-19, practitioner-opinion) puts the industry's current planning enthusiasm in a lineage:

"The temptation is to specify, get the human to specify, specify, specify, specify and then give it to the agent. This is a very old temptation. It was a temptation we underwent in the 70s. It led us to the waterfall process and all of that. And the agile revolution was the answer to that."

His verdict on the modern version is a report, not a prediction — he had been running the experiment the week of the interview:

"I have tried this. In fact, I've been in the middle of trying this just this week and it's always a disaster. And it's always the same outcome: you make all these plans and then as the agents are running, you the human realize that they can't follow that plan because you didn't think of everything and they're not as wise as you are. So they're running half-cocked off on some nonsense that you have to stop, back up, rewrite the plan, and then start them over again. And so I've given up on that."

The failure mode is the classical one, with one new twist#

Waterfall failed because the plan could not survive contact with what building the thing revealed. Martin's account has the same shape with a substitution: the gap is no longer between plan and reality, it is between plan and executor. The agents follow the plan competently past the point where a human would have stopped and asked. "They're not as wise as you are" is the operative clause — a human implementer's judgment was silently absorbing plan defects, and that absorption is what the agent does not supply.

The new twist he names is that agents are unusually good at generating the artifact that fails:

"The agents love to write plans. Oh my goodness, they love it. And they will embellish the plans and the plans will be gorgeous and beautiful and spell out all kinds of details."

A beautiful plan is a stronger commitment device than a mediocre one, which makes the plan-maxing loop (Matt Pocock: "they run their spec through seven different agents") actively counterproductive rather than merely wasted.

The economic argument: cost of change#

His case for the agile answer is the story he used to tell in agile lectures, updated. If every change to a house — including laying the foundation — cost one dollar, nobody would pay an architect thousands for a perfect plan; they would move the kitchen, look, move the stairs, look.

"The cost of change has plummeted to as close to zero as I think we're ever going to get it — and well, that's a prediction I'll probably lose, but still. The cost of change has gone so far down that why would you do this upfront planning? Why wouldn't you just fiddle, fiddle, fiddle, fiddle until it looks right?"

He flags the prediction as one he expects to lose, which is worth preserving: the argument's whole weight rests on the cost of change staying near zero, and that is the falsifiable part. It also quietly presumes the gauntlet — cheap change is only safe if a change that breaks something gets caught, which for him is what the deterministic gates are for (Reviving Impractical Quality Tools).

Specs are ephemeral, and the artifact is the spec#

Asked directly whether he keeps specifications in the repo:

"No, I do not. The specifications are ephemeral, they go away. They change a lot… Instead of creating a specification that defines what I want, or defines what I have even, I look at the end result and say, well, that is the specification."

The reasoning is that source code used to be the final specification because humans wrote it — "well, that doesn't exist anymore. There is still source code but we humans aren't the ones writing it," and he reads the industry's hunger for persisted specs as an attempt to restore a human-authored ground truth that the workflow no longer produces. His own substitute is his tooling: the CRAP scorer, the mutation tester, the dependency-rule checker are the durable statement of what the system must be, and the ephemeral spec is scaffolding.

This lands on the same side as Matt Pocock's existing "doc rot kills — delete PRDs after implementation," reached by a different route: Pocock's worry is stale documents misleading future agents, Martin's is that a persisted spec was never the right kind of artifact.

Where this contradicts the corpus#

  • Planning / Execution Division of Labor measures humans making ~70% of planning decisions across 400K Claude Code sessions. That is a description of what people do, not evidence that heavy front-loading works; Martin's claim is compatible with the split but hostile to pushing it further toward the plan.
  • Design Concept Grilling and Matt Pocock's workflow put substantial structured work before implementation — but the output is shared understanding and a destination document, not an executable plan the agent follows step by step. Martin's target is the second, and the distinction is the one Pocock presses in the interview: "is prompt engineering spec-driven development? Like it kind of is." Neither settles where the line falls; Pocock proposes persistence as the test, and Martin answers it directly by refusing to persist.
  • Vertical Slice Tracer Bullets is the closest existing page to Martin's remedy — a thin slice, then look — arrived at from Pragmatic Programmer rather than from agile.
  • Code as Source of Truth and The Committed-Artifact Chain hold the opposite practice on the point he is most definite about. The first checks specs into the repo so that spec drift can be verified; Anthropic's Applied AI playbook (vendor-claim, 2026-08-21) goes further and makes a committed intent.md → spec.md → plan.md chain the handoff mechanism itself, with the PR reviewed against plan.md. Martin's "no, I do not" refuses both, and the gorgeous plan the agents follow past the point a human would stop is exactly the artifact the chain commits. Neither side has measured anything — the playbook prescribes, Martin reports. The reconcilable part is scope: his target is the executable step-by-step plan, and intent.md is closer to what Design Concept Grilling produces. The irreconcilable part is plan.md.
  • Prototype Over PRD reaches his "that is the specification" from the product side — Dan Carey's prototype is the spec — and The PRD-Replacement Spectrum at AI-Native Speed lays the corpus's positions on one axis from most to least pre-build specification. Martin sits past its right pole: no persisted spec at all, with the durable statement of what the system must be moved into the checkers rather than into any artifact.

What he has not solved#

The agile answer leaves a manual step he cannot remove: "let them do a story or two, and then we'll look at the architecture at the end, and maybe I'll have to manually get involved and sort a few things out." He is trying to automate that architectural reorganization "and I'm having not a lot of luck so far" (Deep Modules for Agents). So the honest statement of his position is not that planning is unnecessary — it is that the planning has moved from before the work to between increments, and that the between-increments version is still human.

Connections#

Open Questions#

  • Does the cost of change actually stay near zero as a system grows, or does it re-inflate at some size — which would restore the case for up-front design and settle Martin's self-flagged prediction?
  • Does storage-per-se move any outcome once content and read-back behaviour are held fixed — the same specification supplied as a committed file vs. pasted into the conversation, with the agent required to re-read it before each decision in both arms, scored on rework, defect rate or drift? Nothing in the corpus runs this; Khatri's with/without ablation harness (the correctness null on the agent-context-files page) is the closest existing instrument. A null retires persistence as even a proxy; a measurable effect gives Is Persistence the Line Between Prompting and Spec-Driven Development?'s authority line its first measured competitor.

Resolved Questions#

  • Is persistence the right definitional line between prompting and spec-driven development, as Pocock proposes and Martin's practice assumes? Answered: Is Persistence the Line Between Prompting and Spec-Driven Development? — no. Persistence is an observable proxy for authority (is later work judged against the artifact?), and it misclassifies the corpus in both directions: CLAUDE.md, WORKFLOW.md, REVIEW.md, the ticket graph and Martin's own dependency-rule file are persistent and returned-to without being specs, while the grilling transcript, Carey's why-conversation and Martin's deleted plans are ephemeral and do the entire specification job. Both cited positions are also misread here: Pocock's sentence is a conjunction — "are you persisting your specifications… are you returning to those specifications?" — and only the second clause survives (he closes rather than deletes the PRD, revoking authority while keeping the file); Martin persists constraints a checker enforces and discards only plans that nothing enforces. practitioner-opinion throughout, and nothing in the corpus measures persistence-per-se.

Sources#

§ end
Cited by 16
Related articles