Software Ships in Loops, Not Waterfalls: How Modern AI Development Actually Works

Short version. Classic software projects plan everything from start to finish and deliver at the end. Modern AI software gets built differently: in short loops, where every pass ends with something working that you can look at, test, and correct. The difference isn't cosmetic. It decides whether an AI initiative reaches production or ends up as an expensive pilot. And that is the most common way AI projects fail.

Why waterfall works especially badly for AI

The classic approach in software development is often called waterfall: plan everything completely, then build it, then deliver at the end. On well-understood problems, that can work. On AI, it rarely does.

The reason is simple. With AI, you don't know at the outset what will actually work well enough. Whether a model reads your documents reliably enough, whether an agent genuinely handles the process end to end, whether the quality holds up in practice: none of that is clear until something is running. A big plan that fixes twelve months of scope in advance is set against a technology whose outcome you cannot know beforehand. That is why so many AI initiatives produce an impressive demo and then nothing that ever reaches production.

How common this pattern is shows up in an MIT study (Project NANDA, "The GenAI Divide", 2025): roughly 95% of the generative AI pilots studied failed to deliver measurable ROI or reach production. Worth being precise here: that is a finding about generative AI pilots, not about AI in general, and not about adopting off-the-shelf tools. But pilots are exactly what's at stake when a company has something custom built. The main reason MIT points to isn't technical, it's structural: the systems don't learn from real use and don't get adapted. That's a waterfall problem.

The build loop

The alternative is a short, repeated loop. One pass looks like this:

1. Build one small piece. Not the whole system, just the next sensible step.
2. Check it immediately. Does it run? Does it solve the problem on real data? Automated tests plus a human look.
3. Learn from the result. What worked, what didn't, and what does that mean for the next step?
4. Repeat. The next pass builds on what was just learned.

Every pass ends with something working, not a status report. That sounds minor, but it changes everything: risk becomes visible early instead of at the end, course corrections cost days instead of months, and nobody spends twelve months building on an assumption that turns out to be wrong.

This way of working isn't new. Agile software development has followed a similar principle for a long time. What's new is that AI coding agents compress the loop dramatically. A pass that used to take a sprint can now take hours. That makes the iterative approach not just sensible for AI, but the only honest option.

Waterfall versus the build loop

What this looks like in practice, with real numbers

One caveat first, because otherwise this piece would make exactly the mistake it's criticizing: the numbers below come from our own work on our own platform. They are not client numbers and not a general study. They show how a small team delivers with this way of working, and they're checkable in our own git history.

Over roughly 36 hours, we shipped around 30 distinct features to production, each as its own reviewed and merged step: 244 changed files and about 32,000 lines of code combined. The test foundation behind that runs to 660 test cases across 76 test files. That speed doesn't come from typing faster. It comes from every step being small, checked immediately, and backed by tests, which is to say, it comes from the loop itself.

Honesty means the other side of that too. Speed without checks is dangerous. One example from our own work: two of our agents once touched the same file at the same time, because an ownership list had missed a dependency, and they collided. Things like that happen when you move fast. The point isn't that nothing goes wrong. The point is that the loop surfaces those mistakes early, where they cost minutes, instead of late, where they cost a release. That's exactly why we build in checkpoints before starting, not after something breaks.

How to tell who you're dealing with

If you're having AI software built for you, your partner's way of working is one of the few things you can actually check in advance. A few questions that make it clear fast:

• When do I see the first working piece? If the answer is "at the end," it's waterfall.
• How often do you ship? Weeks is good, quarters is a warning sign.
• What happens when building reveals that an assumption was wrong? If that's a change order with a markup instead of the next pass, that tells you the model behind it.
• Do you test on real data or only in the demo? A demo proves nothing about production.

We build AI software for production, every day, in exactly these loops. If you want to know how this translates to a specific initiative at your company, that's what a first conversation is for.