I’ve been writing software for over two decades, which is long enough to have been wrong about methodologies in both directions. I’ve rolled my eyes at 200 page requirement documents & I’ve also sat in sprint retrospectives wondering what exactly we were sprinting towards. So take what follows with a suitable pinch of salt; but I think Waterfall deserves a second look & the reason is AI.
Why did Waterfall fall out of favour?!
The idea behind Waterfall is simple enough. You gather requirements, write the specifications, design the system, build it, test it & ship it – each phase finishing before the next one starts. On paper there’s nothing wrong with that. Nobody builds a bridge by pouring some concrete first & asking the client how it feels.
What hurt was the gap between the plan & the product. Building software took months, often years & the world didn’t politely wait while we typed. By the time the thing was built, the business had moved on, a competitor had shipped something or the client had simply changed their mind. Now we had a specification that was out of date & a codebase built faithfully to it. Changing course meant climbing back up the waterfall, which cost a lot of time & money. Every change request turned into a negotiation.
Funny thing is, Winston Royce’s 1970 paper – the one everybody points at as the origin of the Waterfall model – never used the word. It also said quite plainly that doing the whole thing in a single pass was risky & invited failure. We kept the diagram & skipped the warning.
What did Agile fix?!
Agile, which got its name & its manifesto in 2001, went after that gap. Don’t plan the whole thing, plan the next two weeks. Build a small slice, put it in front of people, learn from what they say & adjust. If the requirements change, fine – you’ve lost a sprint & not a year.
Look at what Agile was optimising for though. Writing code was the slow & expensive part of the whole exercise. So the sensible thing was to never write too much of it on the back of a guess. Short iterations were a hedge against the cost of being wrong. Detailed planning in advance was seen as waste, since half the plan would be stale before anyone got around to building it.
That trade made sense for more than two decades. It also came with a price we got used to paying – backlogs that are a plan in everything but name & architecture that gets decided by whichever ticket landed first.
So what has changed?
The cost of building has dropped through the floor. In my experience, an AI coding agent can turn out in a day what used to take a person a few weeks. I’m not claiming the output is perfect – it isn’t & anyone who has reviewed enough of it knows that. But the AI models have come a long way and even if the output requires some adjustments, build times are still way less compared to a human writing that whole thing up by hand. The speed is there & it changes the maths of the biggest selling point of Agile.
Waterfall’s big weakness was the long gap between specification & working software. If that gap shrinks from months to days, the specification doesn’t get the time to go stale. If it does turn out to be wrong, you fix the spec & build again. A rebuild that costs a day isn’t the disaster it was when it cost multiple weeks or months.
Then there’s the matter of how these models work. They do their best work when they’re told exactly what to build. Hand an AI agent a one line prompt & it fills every gap with its own assumptions – some sensible, some bizarre & all of them delivered with 200% confidence. Hand it a detailed spec with the data model, the edge cases, the constraints & what’s out of scope and you get a very different result.
An agent has no memory of last sprint’s hallway conversation. A human team working in Agile carries a lot of context in their heads – why a decision was made, what the client said on that call, which shortcut is temporary. The agent has none of it. Whatever isn’t written down doesn’t exist as far as it’s concerned. So the written specification, the very thing Agile taught us to keep light, is now the most important input to the build.
The industry is already drifting this way, though it avoids the W word. The name doing the rounds is “spec driven development” & tools like GitHub’s Spec Kit & Amazon’s Kiro are built around writing requirements, a design & a task list before any code gets generated. Squint a little & that’s a Waterfall.
But don’t requirements still change?
They do & that’s the fair objection here. A good chunk of requirement churn never had anything to do with slow builds. People often don’t know what they want till they see something working. No amount of planning fixes that & a perfect spec for the wrong product still gives you the wrong product, only sooner.
What AI changes is the price of finding out. Earlier, discovering that the spec was wrong meant months of work in the bin. Now it means you update the document & run the build again. So I’m not talking about the Waterfall of old with its one giant pass & a prayer at the end. I’m talking about the same discipline – think it through, write it down, then build – repeated as many times as it takes, since each round is cheaper now than it was before.
Some will say that’s just Agile with bigger tickets. Maybe. To me the difference is in where the thinking happens. In Agile, as most teams practise it, a lot of the design gets discovered while writing code. With an agent doing the writing, that means the agent is making your design decisions & you find out what it decided during code review. I’d much rather make those calls myself before the build starts.
Where does that leave us?
For project managers this might feel like vindication of sorts – the documents are back. For engineers it means the job tilts away from typing & towards specifying, which is the harder skill of the two. Writing a spec tight enough for a machine to build from will expose every fuzzy bit of thinking that you’d have otherwise papered over in code.
Agile isn’t dead & I’m not about to set fire to the sprint board. Feedback from people who use the software matters as much as it ever did. But we stopped planning in detail because building was slow & plans rotted while we built. Building isn’t slow anymore. If the constraint that sank Waterfall is gone, it’s only fair to ask whether the verdict against it still stands. I don’t think it does.