The premise
The economics moved
Agile won because change used to be expensive. It isn't anymore. The best way to build software with AI looks a lot more like the Waterfall model we spent twenty years moving away from.
I don't say that to be contrary. The two things that made Waterfall miserable are exactly the two things AI just made cheap, and once they are cheap, the shape everyone ran from starts to make sense again.
The old bargain
Why we ran from Waterfall
Go back a few decades. If you wanted software you wrote the specification first, in detail, and only then did anyone build. The military had a standard for it. So did the IEEE. It was slow and heavy, and people hated it for two reasons.
One was money. Changing your mind late was expensive, which Barry Boehm put numbers to in 1981. A fix during design cost a little. The same fix after shipping cost far more. People have argued about the exact multiple ever since, but never the direction.
The other reason was the people. The spec came down from above and turned out to be half wrong the moment an engineer tried to build it. Fred Brooks put it plainly in 1975. Plan to throw the first one away, because you will anyway. You only find out what the spec got wrong by building it, and the person who ate the late change was the one holding the keyboard.
The real variable
It was never sequence versus iteration
Almost everyone gets the history wrong here. The 1970 paper that supposedly invented Waterfall actually argued against running it in a single pass. Winston Royce told you to build it twice and get the customer in early.
The whole argument that followed, Waterfall, then Agile, then every hybrid in between, was never really about sequence versus iteration. It was about the cost of being wrong. Every method was just a different way to manage that one cost.
So when committing early was expensive and changing late was worse, the rational move was to stop committing early. In 2001 seventeen people signed the Agile Manifesto and said it outright. Working software over comprehensive documentation. Responding to change over following a plan. Keep your options open, because options were cheap and being wrong was not. It was less a philosophy than an accounting decision.
The repricing
Then the cost fell out of it
Then AI changed both of the costs the whole argument was built on. Writing the spec used to be the slow part. Now I can draft a detailed one with AI in an afternoon. Building used to be the slow part as well. Now I hand a good spec to a swarm of agents and get a working prototype the same day.
Change is cheap now, in time and in tokens. I can spin up three versions and keep the one that tests best.
Neither cost hits zero. But against what it used to take, an architect to write the spec and an engineer to build to it, both fall by orders of magnitude.
What stops paying
The case for Agile inverts
When the cost of being wrong drops that far, the case for Agile inverts. Not the mindset. Staying flexible about what you build matters as much as ever.
The methodology is the part that stops paying. The sprints and standups were built to ration expensive change. Make change cheap and that machinery is mostly overhead. The agility doesn't disappear. It moves upstream, out of the build and into the strategy.
Two things wear the same name
Being agile about your product, willing to change direction as you learn, is worth more than ever now that you can act on the change the same afternoon. Agile the engineering process is the part that expensive change used to justify. Keep the first. Retire the second.
Under a friendlier name
The industry is already doing this
None of this is theoretical. It's already happening under a friendlier name. The industry calls it spec-driven development. You write an executable spec, treat it as the source of truth, and generate the code from it. When the requirements change you edit the spec, not the code. GitHub shipped a toolkit for it. So did Amazon and Microsoft.
The people building these tools will tell you it isn't Waterfall, and they're right about the part they mean. It isn't big-design-up-front where you predict everything and never touch it again. But look at the shape. Specify first, build from the spec, check the result against it. They kept Waterfall's sequence and threw out its rigidity, because AI finally made the sequence cheap to run again.
The version I'd sign
The manifesto, pointed the other way
So here is the version I would sign. Same format the original used, mostly pointed the other way.
A good specification over tribal knowledge and ceremony
The context used to live in people's heads, which is why you needed them all in a room. Now it lives in the spec, and the spec doesn't quit or forget.
Context and ontology over working software
The code tells you what's happening. The ontology tells you how the pieces are meant to fit together. The writeup used to be the optional part you did after. Now it's the first thing I do.
Customer collaboration over contract negotiation
I'm keeping this one. They got it right in 2001, and cheap software only makes it more true. What changed is the thing you collaborate on. A spec good enough to build and iterate, and a working version you can put in front of the customer the same afternoon, instead of a document that gets filed and forgotten.
Following a plan you can rewrite over reacting without one
You still respond to change. You do it by rewriting the plan and regenerating, not by dropping the plan and keeping everything half-built so it can flex.
The bottom line
What's left is judgment
None of this works if the spec is sloppy. Hand a vague spec to a swarm of agents and you get confident nonsense that drifts from what you meant. That failure is real, and it's the whole reason writing sharper specs and reviewing the output came roaring back. The build got cheap. Being clear about what you want did not, and neither did judgment.
That's the part I didn't expect. When the middle of the work gets automated, the value moves to the two ends. Framing the right problem at the front, and checking the result at the back. My own week is almost entirely those two now. I spend it deciding what to build and reviewing what came back. The typing in the middle is what I hand off.
The people who wrote the Agile Manifesto were right in 2001. The economics they were reacting to were real, and I worked through plenty of them. That world is changing. So before you run the next project the way you always have, a few honest questions.
- What does it now cost you to be wrong, and is that still worth hedging against?
- Which of your agile rituals were solving for expensive change, and what are they solving for now?
- Once the build is cheap, where should the judgment live?