Waterfall Is Coming Back, and It's Not a Joke

Say the word "waterfall" in a software organization and you will get a particular reaction: a wince, a knowing smile, the comfortable certainty that you are describing a discredited past. Waterfall is the methodology we escaped from. It is the thing Agile saved us from. Suggesting it might return is roughly as serious as suggesting we go back to printing requirements on paper and mailing them to the development team.

I want to make the unserious suggestion seriously. A variant of waterfall, the part of it that was always about thinking hard before building, is coming back, and it is coming back for exactly the reason Agile replaced it in the first place: economics. The cost structure of software just inverted. When the cost structure inverts, the methodology that fit the old costs becomes a liability, and the one everyone buried turns out to have been buried for a reason that no longer holds.

This is the companion argument to one I have made before: that Agile, as a methodology, has outlived the conditions that produced it. That piece was about what dies. This one is about what comes back to take its place, and why the thing that comes back looks unsettlingly like the thing we thought we had outgrown.

Agile was a hedge against the cost of change

Start with what Agile was actually optimizing for, because it was never "speed" in the abstract. It was optimizing for cheap correction in a world where building was expensive and being wrong about what to build was catastrophic.

In the waterfall era, the disaster scenario was specific and common: you spent six months writing a detailed specification, six months building exactly what the specification said, and then discovered the specification had been wrong from the start. A year and a fortune, spent producing something nobody wanted. The further downstream you discovered the error, the more it cost to fix. The famous cost-of-change curve, the one that climbs steeply as you move from requirements to design to code to production, was the central fact of software economics for forty years.

Agile's entire design follows from that one curve. If change gets more expensive the later you make it, then the rational response is to make changes as early and as often as possible. Slice the work into the smallest pieces that still ship. Get each piece in front of reality fast. Discover you were wrong while the wrongness is still cheap to fix. Iterate.

Every Agile practice is a tactic in service of that strategy. Small stories exist so that a wrong bet is a small wrong bet. Two-week sprints exist so the maximum distance between a decision and its correction is two weeks. Continuous delivery exists so the feedback loop closes in hours instead of quarters. The minute breakdown of work, the thing teams now do almost religiously, was a hedge. You break a feature into fifteen tickets because if the feature is wrong, you would rather find out after ticket three than after ticket fifteen.

It was a brilliant adaptation. It was also, fundamentally, a response to a price. The price of building, and therefore the price of having built the wrong thing.

AI repriced the building, and the larger work too

Here is the part everyone has noticed: AI made small work nearly free. A ticket that used to take an engineer a day takes an hour. A bug fix that used to require an afternoon of archaeology takes a focused twenty minutes with a model that has read the whole codebase. The marginal cost of executing a small, well-defined piece of work has fallen through the floor.

But there is a second half to this that gets far less attention, and it is the half that matters here. AI didn't just make small work cheap. It compressed the cost of large work too.

The body of work that used to take a team two or three months, a new subsystem, a migration, a feature with real surface area, no longer costs two or three months of grinding implementation. The implementation, the part that used to dominate the timeline, compresses dramatically. What used to be a quarter of typing is now a few weeks of directing. The big thing and the small thing both got cheap to build.

This breaks Agile's core assumption in a way that the "small work is free" observation alone does not. Agile's whole justification for slicing everything into tiny pieces was that big pieces were dangerous: expensive to build and ruinous to get wrong. If a big piece is now nearly as cheap to build as a small one, the safety argument for slicing collapses. You are no longer reducing risk by breaking the work down. You are just adding overhead, the coordination, the ceremony, the seams between fifteen tickets that have to be stitched back into one coherent thing.

The bottleneck moved back upstream

If building is cheap, what is expensive now? The same thing that was always expensive, only now it is the only thing that is expensive: knowing what to build, and designing it so that it holds together.

When implementation dominated the cost curve, thinking was a small fraction of the total. You could afford to think a little, build a little, learn, and think again, because the building was where the money went and you wanted tight feedback on it. Now invert the ratio. Implementation is a sliver. The expensive, scarce, bottleneck activity is the design, the architecture, the understanding of the problem deeply enough to direct an enormously productive build engine at the right target.

Point a coding model at a vague, half-considered ticket and it will produce a vague, half-considered implementation, beautifully formatted, at tremendous speed. The cost of being wrong about what to build did not fall with the cost of building. If anything it rose, because now you can build the wrong thing, all of it, very fast, and the wrongness is no longer caught by the slow grind of implementation surfacing every unconsidered edge case along the way.

The constraint moved back to where it lived before Agile: upstream, in the thinking. And the discipline that was built around doing the thinking before the building was waterfall.

Not the waterfall you're remembering

Now, an important correction, because I am not arguing for the cartoon version of waterfall that deserved its bad reputation.

The waterfall that failed was the rigid, gated, document-worshipping bureaucracy: a six-month requirements phase producing a binder nobody read, sign-off gates that existed to assign blame, a process that treated the plan as sacred and reality as an inconvenience. That waterfall failed because it combined heavy upfront thinking with a punishing cost of change, which meant that when the thinking turned out to be wrong, and it always did, you were trapped. It was not the upfront thinking that killed it. It was the upfront thinking welded to an inability to adapt.

Pull those two things apart and the picture changes completely. The thing that is coming back is the upfront thinking, the genuine design phase, the discipline of understanding a whole body of work before you commit to it. What is not coming back is the rigidity, because AI removed the very thing that made rigidity dangerous. If a design turns out wrong, rebuilding against the corrected design is now cheap. You get the heavy thinking of waterfall without the brittle, change-hostile execution that made heavy thinking a gamble.

• Design the whole thing first. Not a binder, a thesis. A clear, coherent specification of a substantial body of work, thought through to the edges before a line is generated.
• Execute it in one coherent pass. Build the larger piece as a larger piece, directed by AI, rather than dissolving it into fifteen tickets that lose the shape of the whole.
• Keep change cheap by design. Lean on the fact that rebuilding against a revised spec is now inexpensive, so the plan can be ambitious without being a trap.
• Verify continuously, because that is the new expensive thing. The discipline moves to evals, tests, and observation, since building no longer surfaces problems for you on its own.

Call it waterfall, call it a spec-first or design-first model, call it whatever lets you say it in a room without people wincing. The shape is the same: think hard, in depth, about a large unit of work before building it, and then build it nearly autonomously.

Why the minute breakdown of work becomes a tax

Return to the practice Agile teams now perform most reflexively: breaking work down into the smallest possible increments. In the old economics this was pure virtue. Small increments meant small risk, fast feedback, and a manageable cognitive load for humans typing every line by hand.

In the new economics, that same practice quietly turns into a tax, paid in several currencies at once.

It fragments the thinking. A coherent body of work has a shape, an internal logic, a set of decisions that only make sense in relation to each other. Shatter it into fifteen tickets and you have shattered that coherence. Each ticket is reasoned about locally, by whoever picks it up, and the global design degrades into whatever emerges from the sum of local decisions. When humans built slowly, the slowness gave the design time to be felt and corrected. When the build is fast, the fragmentation just locks in incoherence at speed.

It adds seams that have to be re-stitched. Every boundary between tickets is a place where context is lost and has to be rebuilt, where one piece has to be reconciled with another, where the ceremony of grooming, estimating, and sequencing consumes attention. With AI doing the building, this coordination overhead can easily exceed the cost of the building it is coordinating. You are spending dollars to manage the spending of pennies.

It optimizes for a risk that no longer dominates. The small-batch discipline exists to limit the blast radius of a wrong implementation. But the implementation is no longer the risky, expensive part. The risky part is the design, and you cannot reduce design risk by chopping a well-conceived design into smaller execution units. You reduce design risk by thinking harder up front, which is the opposite move.

What this looks like in practice

Concretely, here is the difference between an AI-era team still running on Agile reflexes and one that has shifted upstream.

The Agile-reflex team takes a meaningful feature, breaks it into a dozen stories in a grooming session, points them, distributes them across two sprints, and runs the machinery. AI makes each story fast, so the team feels productive, tickets close at a satisfying rate. Two sprints later they have a feature that works in pieces and doesn't quite cohere, because no one ever held the whole thing in their head at once, the design was an emergent property of a dozen local implementations, and the standups and planning sessions consumed more human hours than the building did.

The upstream team takes the same feature and spends the first chunk of time, more time than feels comfortable, doing nothing that looks like progress. They are writing the spec. Arguing about the data model. Walking the edge cases. Producing a design document that is genuinely thought through, the kind of artifact the Agile era taught us to be embarrassed about. Then they direct an AI to build the whole coherent thing in something close to one pass, against that design, with heavy continuous verification. The building is fast because the thinking is done. And when reality pushes back, as it will, they revise the design and rebuild against it, cheaply, because that is now cheap.

The first team will look busier. The second team will ship something that holds together, in less total human time, with the expensive human attention spent on the one thing that is actually expensive: the design.

Where the other methodologies sit on this

It helps to place the usual suspects on a single axis: how much do you commit to understanding a whole body of work before you build it, and at what level of granularity do you bet? Most of the well-known methodologies are really just different answers to that one question, and AI just moved the right answer.

Classic Scrum

The dominant default. Work is sliced into small stories, pointed, and committed to a two-week sprint. The granularity is tiny by design, and upfront thinking is deliberately minimized in favor of inspect-and-adapt. This is the methodology most exposed by the new economics, because its entire risk model assumes that building is expensive and that small batches are how you keep a wrong bet cheap. When building is cheap and the wrong bet is a design problem, Scrum is optimizing the variable that stopped mattering and starving the one that now dominates.

Kanban

Better adapted than Scrum, because it drops the artificial sprint boundary and the estimation theater and just manages a continuous flow with work-in-progress limits. But Kanban is agnostic about where the thinking happens. It will move a beautifully shaped card and a thoughtless one across the board with equal serenity. It solves the cadence problem, not the upstream-design problem, so it pairs well with a design-first approach but doesn't supply one.

Shape Up

This is the interesting one, and the one that was most prescient. Basecamp's Shape Up already rejected most of the instincts that the new economics punish. It bets on larger chunks of work, not minute tickets. It works in six-week cycles rather than two-week confetti. It drops daily standups and story-point estimation entirely. And, crucially, it puts a dedicated shaping phase up front, where someone thinks the work through at the right level of abstraction, defines the appetite, and walks the rabbit holes, before anyone bets on building it. That shaping phase is, structurally, a lightweight design-first phase. Shape Up was arguing for upstream thinking and larger coherent bets back when building was still expensive, which took real conviction.

AI doesn't refute Shape Up. It amplifies it. Almost every instinct Shape Up had against fine-grained slicing and ceremony gets stronger when the build collapses in cost. The two places it would now bend: the fixed six-week appetite was partly a hedge against expensive building and can flex when the building is cheap, and the shaping phase, which Shape Up keeps deliberately rough to avoid over-investing in a plan that might not be bet on, can afford to go deeper now that a thorough spec is the highest-leverage artifact a team produces and a wrong design is cheap to revise. Shape Up is the closest thing the industry already has to where this is heading. The design-first model is, in a sense, Shape Up with the appetite unbolted and the shaping turned up.

Old waterfall

Maximal upfront commitment, maximal granularity of bet (the whole project at once), and fatally welded to an expensive cost of change. Right about thinking first, wrong about everything that happened when the thinking turned out to be incomplete. The design-first model keeps its one good instinct and discards the rigidity that the cost of change no longer forces on anyone.

Line them up and the trajectory is obvious. Waterfall bet big and couldn't adapt. Agile bet small so it could adapt cheaply. Shape Up bet medium and pushed thinking upstream while staying adaptive. The design-first model bets big and stays adaptive, which was a contradiction in every prior era and is simply available now. Shape Up was walking in this direction a decade early. The new economics just removed the last reason to stop where it stopped.

The objection, and the answer

The obvious objection: "This is just bringing back big upfront design, and we know how that ends, you commit to a plan, reality disagrees, and you're stuck defending a stale spec."

That objection is correct about old waterfall and wrong about this. The thing that made big upfront design dangerous was never the design. It was the marriage of expensive design to expensive change. You thought hard, committed, and then could not afford to be wrong, so you defended the plan against reality because reversing it cost a fortune. The pathology was the rigidity, and the rigidity came from the cost of change.

AI dissolved the cost of change at the execution layer. Revising the design and regenerating against it is now genuinely cheap. So you can do the heavy upfront thinking and stay responsive, because changing your mind no longer means eating a quarter of sunk implementation. You get the part of waterfall that was always good, depth of thought before commitment, freed from the part that was always bad, the inability to adapt once committed. That combination was simply not available before. The economics didn't permit it. Now they do.

This is also why it isn't a return to 2001. It is a genuinely new point in the design space, one that happens to rhyme with waterfall because it restores the primacy of thinking before building. The rhyme is what makes it easy to dismiss and important not to.

What to do about it

If you lead a software organization, the practical moves follow directly.

Stop reflexively breaking work down. Before a team shatters a feature into tickets, ask what the small batches are protecting against. If the answer is "the risk of an expensive wrong implementation," notice that the implementation is no longer expensive, and consider keeping the work whole.

Reinvest the saved time upstream. Take the hours you used to spend in grooming, estimation, and standups and move them into design. Make it normal, even prestigious, for a team to spend real time thinking before building. The design document should stop being an embarrassing relic and start being the highest-leverage artifact the team produces.

Size work to the thinking, not to the sprint. Let the unit of work be a coherent body of work, the thing that has a single clear shape in someone's head, rather than whatever fits in two weeks. The sprint boundary was a hedge against the cost of building. The cost of building is gone. Let the boundary go with it.

Move your process discipline to verification. The rigor you used to spend on planning the build should now be spent on confirming the build. Evals, tests, observability, staged rollout. That is where the new risk lives, because the build no longer slowly reveals its own flaws to you.

Keep the one thing Agile got permanently right. Responsiveness to reality is not negotiable and never was. The point is not to stop responding to change, it is to recognize that you no longer need two-week confetti to do it. You can think big, build big, and still turn on a dime, because turning is finally cheap.

A closing observation

Methodologies are not moral positions. They are adaptations to a cost structure. Waterfall fit a world where building was expensive and the only thing more expensive was building the wrong thing slowly. Agile fit a world where building was still expensive but change could be made cheap by keeping batches small and feedback tight. Both were correct for their economics. Both are wrong when the economics change underneath them.

AI changed the economics underneath both. It made building cheap, all of it, small and large alike, and in doing so it moved the entire weight of the problem back upstream onto the thinking. The methodology that put thinking first, that insisted on understanding the whole before building it, was waterfall. It was buried for a reason that has now expired.

I expect the comeback to be quiet and slightly embarrassed, the way these things usually are. No one will announce that they are doing waterfall again, the word is too radioactive. They will call it spec-first, or design-led, or AI-native delivery, and they will describe it as a brand-new way of working. It will be new, in its details. But the spine of it, think hard about a large thing before you build it, will be the oldest idea in the discipline, returning because the one condition that ever made it a bad idea has finally gone away.