The Methodology No One Saw Coming Back: Why AI Development Feels Like Waterfall Again.

For 20 years, the industry treated waterfall like a cautionary tale. Plan everything up front, the warning went, and you will ship the wrong thing six months too late. Agile won that argument decisively. Then AI arrived, and something strange started happening to real teams: developers began writing detailed requirements before building anything again.

If that sounds like a regression, hold on. The teams doing it aren’t slowing down. They are shipping faster, with cleaner code and fewer surprises. So what is actually going on here? The answer isn’t a return to waterfall. It’s something new that only looks familiar, and the teams that grasp the difference are pulling ahead.

Why AI Pulls You Back to the Blueprint

AI does its best work when it can see everything at once. Humans don’t need that. We hold a rough map in our heads, focus on one piece, and trust ourselves to connect the dots later. AI can’t lean on that instinct.

“In order for it to produce the best work, it needs the whole picture,” says Doug Compton, Principal AI Developer. “It cannot think forward the way a human does, so you have to give it all the information at once. That is more like the waterfall process.”

Feed an agent a thin slice of context, and it will fill in the gaps, but often incorrectly. This causes déjà vu. The model performs better with a complete, coherent specification, bringing back the discipline of front-loading requirements. Agile instincts trained over generations are exactly what these tools need. For a CIO, this redefines a habit you may have spent years unlearning. Detailed planning isn’t slow but essential for leveraging the fastest tool.

This Documentation Does Not Fight Back

Here is where the waterfall comparison starts to fall apart. The old model didn’t fail because it valued documentation. It failed because that documentation was expensive to produce, brittle once written, and disconnected from the people actually building the product.

“In the old waterfall, other roles created the documentation. It was extensive, it was usually wrong, and it was costly to change,” says Chris Howard, CIO. “Now the documentation gets created with AI, so you aren’t as committed to it. You stay open to change, because change isn’t costly anymore.”

That shift alters planning economics: designers or analysts spent weeks writing specs and threw them over the wall, leading developers to implement flawed specs, as rewriting was more costly than shipping mistakes. Today, documentation begins as a quick draft an agent creates in minutes, readable and challengeable by humans and machines before coding. You’re no longer defending a document you spent months on. Instead, you’re shaping a flexible, rewriteable artifact that also serves as testing scaffolding.

Thin Context Fails Fast, Not Slow

Vague requirements always caused problems. What changed is how fast they surface. In the agile years, a fuzzy story could limp along for three sprints before it fell apart. Hand that same fuzzy story to an AI agent, and it breaks right away, then piles more work on top of the mistake. 

“Without a plan, it’s chaos,” Doug says. “The AI guesses at what it thinks is best, and it usually guesses wrong. Then every task after that builds on the bad guess, so the mess only grows.” 

The fix is to treat the spec as a conversation instead of a handoff. Doug lets the agent interrogate him before it writes a line. He always gives the model a chance to ask questions, so anything vague gets surfaced and settled on the spot rather than baked into the build. 

Chris points to a capability waterfall development never had. Teams can now point the model at an existing codebase and ask what a proposed change will actually touch, then think through the ripple effects before committing. The model catches these problems up front, the same ones that used to stay hidden until the team had already built everything else on top of them. 

Waterfall Planning, Agile Building

So is this a reversal of agile? Not quite. The planning looks like waterfall. The building doesn’t.

“The requirements phase feels like waterfall, and it goes smoothly because you have a partner to think alongside,” Doug explains. “But the development is still agile. You build one epic at a time, deploy it, and test it. It’s almost a merge of the two concepts.” 

Meanwhile, the building stays iterative. The work breaks down in layers: epics into stories, and stories into small tasks that take a person an hour or two. A human reviews each finished build before the next one starts. Under the old waterfall approach, the entire system was built before it ever reached QA. That left a six-month or year-long gap between requirements and delivery, and the business logic often drifted in the meantime. That lag disappears here. You keep the upfront clarity and the human-in-the-loop, without waiting a year to find out you built the wrong thing. 

So does all that upfront specification slow a team down? “We lay out the game plan up front, and AI makes that plan far more informed than it used to be. That tends to reduce iterations.” Chris says. The old instinct says more specification means more delay. That math no longer holds. When the plan is right the first time, the team spends its cycles building instead of correcting course. 

Where Skipping the Spec Actually Costs You

The temptation is obvious. AI generates code instantly, so why not skip the planning and let it run? Because the bill arrives later, and it’s steep.

“You end up building a huge amount of tech debt,” Doug says. “The code gets messy, it stops following the architecture, and you duplicate things that should be consolidated.” 

Chris takes it further, to what that mess costs once the system is live. “When something gets used across the system, we try to implement it once, so a future bug only has to get fixed in one spot,” he says. “Without a plan, AI tends to build things one-off, and you end up with inconsistencies and a mess to maintain later.” He also folds security and architecture standards into what counts as documentation, not a separate checkbox. Skip those, and you don’t just inherit messy code. You open genuine security gaps as the system comes together. 

This is the trap worth naming for any leader chasing early velocity: the efficiency looks real on day one, and the cost starts showing up soon after. Speed without a spec isn’t speed. It’s deferred cost with interest. 

What Pays Off Monday Morning

When deciding where to start, the highest-leverage moves are the least glamorous ones. Begin with what AI can touch without risk: your existing documentation and a test net around the code you already run.

“Have AI go through your codebase and create a unit test suite to verify the existing functionality, and highlight some bugs you already have,” Doug says. “Once you have that in place, making changes is safer, because you are verifying you aren’t breaking other things.”

That net is what unlocks the rest. Once the tests are in place, a CI/CD pipeline can run them on every commit, review the code, and scan for security vulnerabilities and leaked secrets on its own. None of it’s flashy. Together, it turns AI from something that can quietly break your system into something that guards it.

Chris adds a step most teams overlook. “A lot of companies already have standards, whether it’s brand guidelines, security requirements, or an architecture the team likes to use,” he says. “Gather that up, centralize it, and teach AI about it. Once it’s aware of those things, it pays off.” The investment you already made in documentation becomes fuel the moment you put it in a format the model can actually use.

There is a readiness signal here too. Teams built for this don’t rewrite prompts from scratch every time. They build a reusable library of AI skills: small, repeatable definitions that draft specs, review them, or run research before requirements. Doug’s advice is to map your current workflow, then convert each step into a skill the model can run for you. Start simple. The budget tends to move in your favor along the way, since design spend drops as AI accelerates the work, and the cost of licensing and tokens hasn’t been the wall teams fear.

The deeper principle involves leadership. The costly misunderstanding Chris sees is either trusting AI too much or not at all. The answer lies in the middle, where AI creates the first draft and experts review and refine. This pairing ensures quality.

Familiar on the Surface, Different Underneath

The reaction makes sense. Writing requirements, more documentation upfront, and planning before coding align with the traditional waterfall methodology, but this version differs. It creates documentation in minutes instead of months, treats change as cheap, breaks work into small, iterative chunks, and keeps humans involved throughout. Upfront clarity is real, and bureaucracy, handoffs, and fear of change are gone.

Waterfall asked you to predict the future and punished you when you got it wrong. This asks you to think clearly and rewards you for doing so. You finally get both: the clarity of a real plan and the speed of a sprint. No trade-off required. 

Slingshot