Agile Was a Coping Mechanism. What Replaces It Isn't Waterfall.

The short version

Brian Carpizo published a piece called "Agile Is Dead. AI Killed It. Welcome Back, Waterfall." He's right about the diagnosis. Agile was a rational response to two real 1990s constraints: humans were bad at comprehensive planning, and building was slow. Both constraints just collapsed. The ceremony economy that grew on top, Scrum Masters, story points, planning poker, half-day sprint planning meetings, was always overhead, and AI made the overhead impossible to justify. He's wrong about the destination. What replaces Agile isn't waterfall. It's a spec-first loop where the architecture document gets written WITH AI in an afternoon, fed back into AI as primary context, and validated against working software inside a week. Waterfall failed because humans couldn't plan well. AI removes that constraint. The right answer isn't to pretend the constraint never existed; it's to do the planning, properly, in hours instead of months, and keep the feedback loop. The thing dying isn't iteration. It's the planning aversion that got dressed up in Agile language for thirty years.

Brian Carpizo just published a piece called "Agile Is Dead. AI Killed It. Welcome Back, Waterfall." It deserves a careful read. He's done the work of articulating something a lot of practitioners have been feeling and haven't said out loud.

Here's what he gets right.

The diagnosis is correct

Agile was a rational response to two constraints that were both real in the 1990s. Humans were bad at comprehensive planning, so we couldn't write a useful 200-page spec at the start of a project. Building was slow and expensive, so we couldn't afford to be wrong at scale. Given those two constraints, "plan less, course-correct more" was the right move.

Both constraints are gone now. Not evolving. Gone.

The first constraint, planning ability, broke when AI got good enough to act as a tireless system-architecture partner. I can sit down with Claude at 9 a.m. and have a full architecture document by lunch. Data model, API contracts, dependency map, eval rubric, the works. Not a hand-wave. A document an engineer could actually build from. The thing Agile was avoiding because it was too hard to do well, AI does cheaply, in hours, at a level of coherence that couldn't be produced in the 1990s no matter how many people you threw at it.

The second constraint, build speed, broke when prototypes got fast. I've sat with a customer at 10 a.m. and shown them a working prototype of their request at 11. The whole "ruthlessly incremental because we can't afford to be wrong" calculus assumed a build cycle measured in weeks. With AI, the build cycle for a useful prototype is measured in hours. You're not betting big when you build a working version in one morning.

So the diagnosis is correct. Both constraints are gone, and the methodology built around them is overhead.

What I'd sharpen is the destination.

"Welcome back, waterfall" is the wrong frame

The waterfall disasters of the 1990s weren't a planning problem. They were a planning ability problem. Teams tried to write comprehensive specs and got it wrong because humans, working alone, in a slow-feedback environment, cannot hold a complex system in their heads coherently for months at a stretch.

What replaces Agile in 2026 is not waterfall. It's a different beast and it deserves its own name. I've been calling it the spec-first loop.

“

Waterfall had no working software for months. The spec-first loop has working software in days, and the architectural coherence Agile gave up on because the planning step was too painful.

”

The five moves. Write the spec WITH AI in hours. Treat the document as a context payload, not a contract. Hand it to AI tools as the primary input for everything that follows: code generation, test scaffolding, infra setup, customer briefings. Build the first working prototype the same day or week. Put it in front of real users by end of week two. Then iterate, with the spec as a living artifact that gets updated as you learn.

That isn't waterfall. Waterfall had no working software for months. The spec-first loop has working software in days, plus the architectural coherence that Agile teams gave up on because the planning step was too painful.

Calling it "waterfall" is rhetorical. It activates the right defensive responses in people who lived through the 1990s. But it mis-describes what the AI-era operating model actually does. The thing that comes back isn't the failure mode. It's the discipline of holistic thinking, now affordable in ways it wasn't before.

What's actually dying

When I read Carpizo's piece, I had a slightly different list of what's dead than he does. His list is the ceremonies: daily standups, planning poker, sprint reviews, retrospectives. He's right that those are dying, and I'd add three more.

The PM-as-translator role. For years, the product manager's actual job in most companies was being a middle-management buffer between engineers who couldn't articulate what was possible and stakeholders who couldn't articulate what they wanted. AI tools eliminate most of that gap. A senior engineer with Claude can produce a stakeholder-ready spec in an afternoon. A stakeholder with Claude can write a coherent feature ask. The translation layer was always overhead. AI made it impossible to justify.

The estimation theater. Story points were always a polite fiction. Velocity was always a metric that everyone learned to game and then pretended was real. AI removes the constraint that made imprecise estimation tolerable, which was that no one could be more precise than that. Now you can. So the polite fiction stops being polite.

The "we'll figure it out next sprint" intellectual habit. Carpizo names this and it's worth repeating. Iterative delivery was always supposed to reduce the cost of being wrong, not eliminate the obligation to think deeply. Somewhere along the way the second one got smuggled in and Agile-as-thinking-replacement became the working culture in a lot of teams. AI is unforgiving on this. Give it a half-formed thought and it gives you a half-formed system, at scale, fast. The cost of not thinking deeply just went up.

What survives

I want to be careful here, because Carpizo's piece reads to some Agile practitioners like an attack on iteration itself. It isn't, and shouldn't be.

The customer feedback loop survives. Shipping working software to real users on a fast cadence is not a methodology fashion. It's the only way you find out you were wrong. AI does not change that. It actually makes the feedback loop more valuable, because the cost of being wrong at scale is now higher. You can ship a lot of wrong-thing fast. The cure is the same as it always was: ship, watch, adjust.

The empowered team survives. The Agile insight that small, autonomous teams beat big, coordinated ones is, if anything, more true now. AI is a per-person multiplier. A team of four sharp builders with full AI tooling out-performs a team of twenty in coordination structures, by a margin that's becoming embarrassing.

The bias toward working software survives. Agile got this right. Documentation that isn't accompanied by something running is a planning artifact, not a deliverable. The spec-first loop doesn't change this. The spec is the input; working software is still the output.

What dies is the ceremony economy and the planning aversion. What survives is the feedback loop and the empowered team. That's not a small reorganization. It's a different operating model.

What this means for the PM seat in 2026

If I'm a PM reading Carpizo's piece, here's the part that should make me uncomfortable.

The job I was trained for, mediating between stakeholders and engineering, writing PRDs, running roadmap meetings, managing sprint capacity, was a job that existed because of the two now-dead constraints. It's the methodology layer. AI doesn't kill the PM as a function. It kills the methodology-protection version of the role.

The version that survives, and gets more valuable, is the PM as specification author and outcome owner. The person who writes the system-level spec WITH AI. The person who decides what to build, who articulates it crisply enough that AI can build it, and who owns the metric that says whether it worked. That role gets more leverage in an AI-era operating model, not less.

If you're in the PM seat and your time is mostly absorbed by ceremonies, you're in the dying part of the role. If your time is mostly absorbed by writing the spec, running customer interviews, and watching the metric, you're in the part that's about to get more important.

This is the same argument I made in The PM Role Is Being Rewritten in Real Time and in Kill the PRD. The Prototype Is the Spec.. Carpizo's piece sharpens it from the engineering side. The two views are converging on the same conclusion.

Pick one thing to try this week

Find the next non-trivial feature on your team's backlog. Before sprint planning, sit down with Claude (or your AI partner of choice) and write the actual specification: system architecture, data model, API contracts, the user journey, the metric you'll watch. Time-box it: half a day, no more. Then take that document to engineering instead of the usual story breakdown.

You'll learn one of two things. Either the team builds the feature 3x faster than usual because they have a real spec to work from, or you'll find out where your team's actual bottleneck was (probably not in story-point estimation). Either result is valuable.

The 1990s couldn't write a useful spec in half a day. We can. The methodology that grew around the inability is overhead now. Strip the overhead, keep the feedback loop, write the spec, ship the prototype, watch the metric.

That's the operating model.

---

Source: Brian Carpizo, "Agile Is Dead. AI Killed It. Welcome Back, Waterfall." (Medium, March 2026).

Related reading: Kill the PRD. The Prototype Is the Spec. · The PM Role Is Being Rewritten in Real Time · Outcome Accountability Is a Luxury Good · The Product Operating Model.