Why AI Is Making Waterfall-Style Requirements Attractive Again

For a long time, we’ve treated requirements as something flexible—something you figure out as you go. Agile pushed that thinking hard: ship fast, learn from users, adjust along the way. And for the most part, that worked.

Now AI shows up, and the natural assumption is that this whole cycle just speeds up. Faster builds, faster iteration, faster learning. But there’s a catch—speed doesn’t clean up ambiguity, it just scales it. What used to be a small misunderstanding can turn into something much bigger, much faster.

You see this even more in environments where things are expensive, regulated, or just very black and white. When compute isn’t cheap, when decisions actually matter, when “close enough” isn’t acceptable—figuring it out later stops being a strategy and starts being a problem. AI is extremely dependent on how clearly you define the problem upfront. Better requirements lead to better outputs. It’s that simple, and that unforgiving.

That doesn’t mean we’re suddenly great at writing perfect requirements. We’re not. We never will be. You still need iteration. You still need to learn from real users. That part doesn’t go away.

What has changed is the cost of getting it wrong early. With AI, vague thinking doesn’t just slow you down—it compounds. So teams may start to shift a bit. Spending more time upfront getting clear on intent, shaping inputs, thinking through edge cases before they start building. Not because they love process, but because AI might start to push things in that direction.

And yeah, it starts to feel familiar. Not full Waterfall requirements gathering. But not the Just In Time of Agile requirements anymore. Something in between.

More upfront clarity where it matters. Iteration where it’s still needed.

We’re not going back to Waterfall. But we might be moving into a world where thinking harder before building isn’t optional either.