Spec-driven development is not waterfall, and the comparison is lazy

Mention spec-driven development in any engineering forum and within three replies somebody will say it is waterfall with extra steps. The line always lands. It signals that the speaker has been around long enough to have seen this before, and it ends the conversation without anyone having to defend a position.

It is also wrong, and wrong in a way that matters, because the objection it borrows was never about specification in the first place.

What actually killed waterfall

Waterfall did not fail because teams wrote things down. It failed because of four specific properties, and it is worth naming them rather than gesturing at the shape.

The specification was written once, at the start, when the team knew least about the problem. It was written by people structurally distant from the building, so what construction taught nobody could feed back. Revising it was expensive and political, requiring sign-off from people who had moved on. And it was large, covering an entire system before any of it existed, which meant most of it was obsolete before it was read.

Now check a machine-checkable acceptance criterion attached to a ticket against that list.

The comparison survives because both practices involve writing down what you want before building it. That is not a meaningful similarity. It is the definition of intending anything at all.

The real objection, which nobody makes

There is a good argument against spec-driven development and it is not the waterfall one. It goes: precision is expensive, and you are moving the cost onto people who do not experience the benefit.

That is true and it is the reason this fails in practice when it fails. The product manager who spends the extra ten minutes making a criterion checkable does not get those ten minutes back. The benefit lands downstream, in a reviewer’s queue, on a team they may not sit with, and it is invisible. Meanwhile their own performance is measured on throughput of tickets, not on the checkability of the ones they wrote.

So the discipline decays exactly where you would predict: under deadline, on the tickets that matter most, written by the person with the least slack.

Anyone advocating this without an answer to that incentive problem is selling a practice that will survive one quarter.

What changed to make it worth the cost

Two things, and only one of them is about agents.

The first is that the reader changed. A requirement written for a colleague is deliberately underspecified, and that was correct: full specification is expensive, and it was cheaper to write “sensible rate limits” and rely on a reader with six months of context who would ask if unsure. When the reader is a system with enormous fluency, no stake, and no memory of your last incident, the gaps get filled by a confident guess instead of a question.

The second is subtler and applies even with no agents at all. When a criterion is checkable, “is it done” stops being a negotiation. That question consumes a startling amount of senior attention in most organisations, and it is a bad use of it. Moving a decision from implementation time to specification time is a win regardless of who implements.

Not a spec:  "Rate limit the public API sensibly."
A spec:      Per API key, not per IP.
Internal service traffic exempt.
429 with Retry-After on rejection.
Counter shared across instances.
Existing keys above the limit are
warned for 14 days, not cut off.

Where this breaks down

Plenty of work resists it, and forcing it produces theatre. Spikes, research, prototypes, anything where the goal is to learn rather than to deliver a known outcome. Writing acceptance criteria for an investigation produces a fictional artifact and teaches the team the practice is a box to tick.

Precision can be a way of avoiding a decision. A criterion that is extremely specific about the response code and silent on whether the feature should exist is precise about the wrong layer. I have seen specification used as a substitute for product judgement more than once, and it is harder to spot than vagueness because it looks like rigour.

The waterfall crowd is right about one thing. If your criteria are written by a separate function, in a separate meeting, and handed over rather than argued out, then the distance that killed waterfall has been reproduced faithfully. The practice depends on the authoring happening near the building. Where it does not, the objection lands after all.

And “up to 50% fewer errors” is a controlled-study number. It comes from research on human-refined specs, and controlled conditions are not your Tuesday. Treat it as evidence the direction is real, not as a figure you can forecast against.

The takeaway

The waterfall comparison is a way of not engaging. Waterfall failed because specification was distant, one-shot, expensive to revise and system-wide, and a criterion attached to a ticket is the opposite on every one of those axes.

The argument worth having is about cost and incentives: precision is real work, it lands on someone who does not collect the benefit, and unless that is addressed the practice decays under exactly the pressure that makes it valuable.

If you take one thing into next week: look at who writes your acceptance criteria and what they are measured on. That answers whether this can work in your organisation better than any argument about methodology.