For twenty years, “Agile vs Waterfall” has been a rigged debate. You were either shipping biweekly with story points and retros, or you were a dinosaur writing 80-page requirements docs nobody would read. One was engineering; the other was malpractice. The jokes wrote themselves.

Here’s the thing. The jokes are aging badly.

Not because Agile was wrong — it was right for the problem it was solving. But the problem has quietly changed underneath it, and a lot of teams haven’t noticed. The economics that made Agile inevitable in 2005 don’t hold anymore. What’s coming back in its place looks, from a squint, an awful lot like the thing we all laughed at.

Why Agile won

Agile won because predicting software was a disaster. You’d write a spec for a six-month project and by month two you’d discover a whole subsystem you didn’t know existed, a library that didn’t do what the docs claimed, an integration that needed three times the code you estimated. The requirements would shift under you anyway because the business didn’t really know what it wanted until it saw something running.

So we gave up on prediction. Short cycles. Working software over comprehensive documentation. Respond to change over following a plan. The Agile Manifesto wasn’t a methodology, it was a surrender — a graceful one. If you can’t see far, don’t plan far. Take a step, look around, take another step.

This was the correct response to a specific constraint: writing code was expensive, and figuring out what to write was almost free by comparison. Planning meetings, specs, design docs — those were cheap. Actually building the thing was the bottleneck. So you optimized by building the smallest useful thing, seeing what you learned, and adjusting.

The ratio mattered. Exploration was cheap, execution was expensive, so you kept execution tight and let exploration wander.

What AI changes

Flip the ratio.

With a competent coding agent, writing the code is no longer the bottleneck. You can describe a feature at breakfast and have a working implementation by lunch. Not always good, not always right, but working. Three implementations if you want to compare them. The “can we even build this” question, which used to eat sprints, now eats afternoons.

What’s expensive now? Knowing what to build. And — this is the part people are still catching up to — specifying it precisely enough that the fast execution produces something coherent.

An agent will happily generate 4,000 lines of code from a vague prompt. The code will run. It will also be the wrong abstraction, ignore the three constraints you forgot to mention, and quietly invent APIs that don’t exist. The bottleneck isn’t typing anymore. It’s thinking clearly enough that a fast, literal, tireless collaborator doesn’t faithfully execute your confusion at scale.

This is the reversal. Exploration is now the expensive part. Execution is cheap. And when execution is cheap, the value of getting the plan right before you execute goes way up.

The return of the design doc

Watch what the people building seriously with AI actually do. They’re not typing please build me a web app into an agent and calling it a day. They’re writing specs. Long, carefully-considered specs. DESIGN.md. PLAN.md. Architecture decisions written out in prose before a single file is generated. Threat models. Sequencing docs. Capability boundaries spelled out in English because the agent needs them spelled out in English.

The artifact that matters has shifted. It used to be the code — the code was the truth, the spec was a lie people told themselves at the start of a project. Now the spec is where the thinking happens, and the code is a compilation target. A cheap one. Rerunnable.

This is Waterfall, or at least Waterfall’s ghost. Not the cartoon version where a BRD gets thrown over a wall to engineers who throw binaries over another wall to users. The underlying instinct: think carefully, write it down, then build. The reason it failed in the 90s was that the “then build” step took two years and the world moved on. The reason it’s viable now is that the “then build” step takes a weekend.

What “Waterfall” looks like in 2026

It doesn’t look like a Gantt chart.

It looks like a single engineer spending three days on a design doc and four hours on implementation. It looks like spec-driven development where the spec is the repo’s most-edited file. It looks like PRs where the interesting review comment is on the architecture markdown, not on the code. It looks like product work where you iterate on the description of the feature through a dozen revisions before anyone writes a test.

Short feedback loops haven’t gone away — they’ve moved upstream. The loop used to be: ship, measure, learn, adjust the backlog. Now the loop is: spec, generate, read, adjust the spec. You can run that loop five times in an afternoon. You’re still being agile in the lowercase sense. You’re just doing it in the design phase, because the design phase is now where the uncertainty lives.

What this means for teams

The uncomfortable part. A lot of Agile ceremony was scaffolding for the fact that individual engineers couldn’t be trusted to plan the whole thing — not because they were bad, but because planning the whole thing was genuinely impossible. Sprints, standups, and story points were risk-management for a world where humans wrote every line by hand and drifted in predictable ways.

When one person with a clear spec can produce what used to take a team a quarter, the ceremony starts looking expensive. Not useless — expensive. A standup where four people sync on yesterday’s tickets is a fine ritual when everyone’s producing at human speed. It’s a strange ritual when one of them shipped the feature overnight and the other three are still describing theirs.

The teams that seem to be winning right now are doing something that looks almost old-fashioned: small groups, lots of writing, careful sequencing, long thinking phases, fast execution phases. They have strong opinions about architecture before they touch a file. They push the uncertainty into the design, not the sprint.

The long live part

Waterfall isn’t literally coming back. The thing it got wrong — betting a year of work on a spec written before you knew anything — is still wrong. Specs are still usually wrong on the first pass. The difference is that the cost of being wrong has collapsed. You write the spec, generate the system, read it, realize the spec was incomplete, fix the spec, regenerate. The loop that used to take eighteen months takes an afternoon.

What we’re converging on doesn’t have a clean name yet. Spec-driven. Design-first. Intent-oriented. Pick your poison. It borrows Waterfall’s seriousness about thinking before building and Agile’s humility about not knowing the answer up front. It’s less a methodology than a new ratio: planning is expensive again, execution is cheap, and the practices that survive will be the ones that respect that.

Agile won the last war. That war is over. The code is writing itself now. Someone still has to decide what it should say.