Those declaring a waterfall comeback because developers now write more upfront specification have misunderstood agile — and waterfall. AI-driven development does not bury the agile principle. It delivers it more completely than any sprint ever did.
What is agile software development? Sprint ceremonies, daily standups, and a Jira board that somehow never gets shorter? And what is waterfall? Writing a specification document before anyone writes a line of code?
If those definitions feel roughly right, the current wave of "agile is dead" and "waterfall is back" commentary makes perfect sense. The trouble is that agile, in most organizations, long ago drifted into something considerably thinner than the original movement intended — and that real waterfall projects, where changing a requirement meant renegotiating a contract, are rarer in most people's direct experience than the confident commentary might suggest.
Titles like "Waterfall Per Increment: How Agentic Coding Changes Everything" and "Agile Is Dead: Long Live Agentic Development" have been circulating since 2025 and are finding new audiences in 2026. They do identify something real: working effectively with AI agents requires more upfront clarity than most teams have practiced. But they have misread the implication so thoroughly that they have arrived at the opposite of the truth. We are not moving back toward waterfall. We are, for the first time, working in a way that fully delivers on what agile always promised. The rituals are dying. The principle is not.
What Actually Happens When You Work With AI Agents
Anyone who has built with AI agents will recognize the pattern from direct experience. You write a product requirements document — as precise as you can make it, with context, constraints, and intended behavior specified. You run the agent. What emerges is close to what you had in mind, but not identical.
This is not a malfunction. It is the fundamental problem of requirements work: the gap between stated intention and actual result has existed in every software project ever undertaken. Requirements are always less complete than they appear until they meet something concrete. Agile methods were invented precisely to surface that gap quickly, rather than letting it accumulate invisibly over months.
With AI agents, the gap becomes visible faster than it ever has. What previously surfaced after a two-week sprint now surfaces in hours. What follows is a cycle: you see what was produced, you understand more clearly what you actually wanted, you revise the requirements, you run again. That is iterative-incremental work. The pace has changed; the structure has not.
If agility means the capacity to respond to change, the meaningful measure is how quickly you move from intention to feedback. In waterfall projects, that cycle took months. In early agile teams, it took weeks. With AI agents, it takes hours. By any reasonable definition of agility, that is not regression. It is the most direct expression of the agile idea that software development has ever seen.
Why the Critics Misread This
The "Agile Is Dead" articles are describing the death of ceremony — not the death of principle. When one of these pieces describes agentic systems as "autonomous, goal-driven, iterative behavior within well-defined constraints," it is describing agile practice. The authors have found a more direct expression of the agile idea and called it something else.
The more careful articles, like "Waterfall Per Increment," make a genuinely sound observation: specification quality has become the primary bottleneck in AI-assisted development, replacing implementation speed. Teams that invest in clear requirements and evaluation harnesses outperform those that simply added AI tools to unchanged workflows. This is true, and it matters. But attaching the label "waterfall" to this observation creates more confusion than clarity. What these articles describe — detailed requirements within each increment, fast feedback between increments, continuous adjustment of direction — is iterative-incremental development. It has been for twenty years.
A related argument holds that writing full PRDs rather than small user stories represents a methodological step backward. This misunderstands both artifacts. User stories were never designed to replace product vision — they were designed to decompose it into buildable units. Behind every well-formed user story there should be a prior understanding of the product's purpose, the user's broader journey, and the strategic rationale for prioritizing this feature now over other possibilities. Methods like the Kano model and Jeff Patton's user story mapping exist precisely because user stories alone are insufficient. If a team was writing stories sprint by sprint without that broader product understanding, that was not agile working as designed. That was agile without product management discipline.
AI agents, unlike experienced developers, do not fill gaps with judgment and contextual knowledge. Weak product thinking, previously obscured by teams that could navigate implicit context, is now immediately visible in the output. What looks like a methodological shift is often a long-overdue reckoning with the product management work that should have happened all along.
What Waterfall Actually Was
The defining characteristic of waterfall was not specification. Every development methodology involves specification of some kind. What made waterfall what it was — what caused it to fail repeatedly and at scale — was the structural impossibility of adaptation.
In a real waterfall project, requirements were written for months, often producing documents running to hundreds of pages. Implementation followed, also over months. Testing came after that. Only at the end, when the system was finally demonstrated to the customer, did it become clear that the wrong thing had been built. Requirements had shifted during implementation. The customer had not known what they actually wanted when writing the specification; they only discovered it when they saw something concrete. The damage was not caused by too much planning. It was caused by systematically deferring feedback to the end of the process. Change mid-project was not merely difficult; it was structurally forbidden — by contracts, by organizational layers, by a process that had designed adaptation out of itself.
Writing a PRD before running an AI agent has nothing to do with any of this. An architect draws plans before the walls go up. Nobody calls that waterfall.
What the Agile Manifesto Actually Says
In February 2001, seventeen software developers met in Snowbird, Utah. What they produced was not a methodology. It was a value system, written out of exhaustion with heavyweight processes and the failures those processes kept generating. The Agile Manifesto states four value pairs:
Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.
No mention of sprints. No mention of standups, story points, or sprint reviews. The manifesto is a compass, not an instruction set. Among its twelve principles, the final one is the least cited: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Restructuring your workflow in response to new tooling is not a deviation from agile. The manifesto explicitly requires it.
Scrum is not a synonym for agile. Ken Schwaber and Jeff Sutherland wrote in the Scrum Guide that Scrum is "a framework within which you can employ various processes and techniques" — intentionally incomplete, designed to be adapted to context. Many organizations never understood this. They allowed Scrum to calcify into a fixed ceremony schedule: standups that became status reports, sprint planning sessions spent arguing over story points, retrospectives that produced no consequential changes. That is not Scrum, and it is certainly not agile.
SAFe — the Scaled Agile Framework — represents the furthest extreme of this drift. Its centerpiece, PI Planning, commits teams months in advance to what they will deliver. That is a quarterly waterfall with agile vocabulary applied to it. Ron Jeffries, one of the Agile Manifesto's authors, has said publicly that SAFe represents a significant departure from agile thinking. Someone whose only reference point for agile is SAFe, or a Scrum implementation that has calcified into ceremony, has a picture of agile that was already distorted before AI agents entered the conversation. When that person reads that AI-driven development requires stronger upfront specification, it does not match their picture. They conclude agile must be dying. They never experienced it, so they cannot recognize it when they see it.
The Principle Outlasts the Tools
Alistair Cockburn, one of the seventeen signatories of the Agile Manifesto, once put it simply: "Agile is an attitude, not a technique with boundaries." Detached from its software context, agility describes something more fundamental — the capacity to sense change, absorb it, and respond without losing direction. That capacity has never been more valuable — and the tools to exercise it have never matched it better.
The question of whether agile survives the AI era is therefore the wrong question. It survives — it has already survived decades of misapplication, bureaucratic distortion, and frameworks that called themselves agile while systematically removing adaptability from their design. What changes with every new generation of tooling is the form agility takes, not the underlying disposition it requires.
The real question is whether the people building software are agile enough to adapt to ways of working that are changing faster than most methodologies can track. That requires someone in the room who understands the difference between the principle and its current expression — and who knows which ceremonies to let go of without losing what made them useful in the first place.
AI did not bring waterfall back. It forced what agile teams should have understood from the beginning: clear thinking before action, and faster learning after it. That is not a retreat from the agile idea. It is, at last, its most direct expression.
Those declaring agile dead with such confident finality are doing so with a rigidity of thought that the original movement existed, in part, to challenge.