A startup reportedly tripled its development productivity by ditching iterative delivery, writing exhaustive upfront specs, and handing the whole thing to an AI agent to execute. The story is making the rounds. And honestly? It's compelling. It's also a clean example of where AI software delivery is heading right now, for better and worse.
But nobody seems to be asking the obvious question. Did they ship something customers actually wanted?
That's the trap in AI software delivery right now. AI makes it easier to build more, faster. A lot of organizations are treating that as a reason to go bigger. Bigger releases. Longer planning cycles. More features bundled into a single drop. It feels logical. It isn't.
Why Big Plans Are Back (and Why That's Partly Right)
Let's be fair. There's a real reason organizations are revisiting upfront planning.
When you're coordinating AI agents to do the building, context matters more than ever. A vague brief produces vague code. You need to define what you're building, why, and how the pieces connect before you hand it off. As one piece going around puts it: AI is extremely good at following exact instructions, and terrible at filling in the blanks.
So yes, clearer upfront thinking is valuable. Getting alignment on the North Star before spinning up agents? Smart. That part of the argument holds.
Where the Logic Breaks
What doesn't hold is the leap from "we need better context" to "let's lock everything in and do a big-bang release in 12 months."
Those are two very different things. One is strategic clarity. The other is a project plan masquerading as one.
The Problem AI Software Delivery Hasn't Solved
Here's the thing about iterative delivery that gets forgotten in conversations about AI speed. It was never just about reducing delivery risk. It was about reducing business risk.
Getting something in front of a real customer. Watching what they do with it. Finding out whether your assumptions were right before you've committed a year of effort to them.
When you bundle everything into one large release, you lose that feedback. And the data on what happens when you do is pretty stark.
According to the Standish Group's long-running CHAOS research, 64% of software features are rarely or never used by the people they were built for. Pendo's more recent analysis of real product usage puts that number at 80%. Eight out of ten features, rarely or never touched.
And yet organizations keep shipping bigger releases, measuring success by whether things shipped to spec. AI doesn't fix that. It just makes it faster to fill the spec with things nobody needed.
The Productivity Story Is More Complicated Than You Think
Before you redesign your delivery model around AI speed, it's worth looking at what the evidence actually says.
A randomized controlled trial published by METR in July 2025, using the same methodology as clinical drug trials, found that experienced developers using AI tools took 19% longer to complete real work on complex codebases than developers working without AI. The part that really stings: those same developers estimated they had been 20% faster.
Here's the part that stings. Those same developers estimated they had been 20% faster. The gap between how productive AI made them feel and how productive they actually were was nearly 40 percentage points.
The Organizational Picture Isn't Better
At the organizational level, the picture isn't much better. The Faros AI Productivity Paradox Report, drawing on telemetry from over 10,000 developers across 1,255 teams, found that developers using AI were writing more code and completing more tasks, but companies weren't seeing measurable improvement in delivery velocity or business outcomes.
More code. Same outcomes. Sound familiar?
This doesn't mean AI isn't useful. It means the gains are real in specific conditions and fragile in others. Basing a return to big-bang releases on the assumption that AI has solved the delivery problem is a bet built on incomplete evidence.
The Feature Parity Trap
There's one version of this I keep seeing that deserves its own callout.
The reasoning goes: our competitors have these features, so we need them too. It sounds like strategy. It isn't.
Your competitor's customers may not look like your customers. And even when they do overlap, the reason someone chose a product often has very little to do with the feature list. If you talk to the actual customers of your competitors, you'll find that out of everything on offer, most of them use one thing. The other features caught their attention. They're not why those customers stayed.
So you spend a year building feature parity. You end up with a product that's equally mediocre at ten things instead of genuinely excellent at one.
The better question is simpler: what's the one thing those customers actually love? Can you do that better, faster, or in a way that fits your customers more specifically?
That's the question AI should help you explore faster. Not help you skip.
What to Actually Do With This
Here's how I'd think about it.
Keep the long-range view. A clear sense of direction, a rough sequence of what you're building and why. That's still valuable, and it's more valuable now that you're giving AI agents context to work with. That part of the project mindset is worth keeping.
But keep the delivery small. Iterative. Tied to real outcomes and actual customer feedback. That's not a methodology preference. It's how you find out whether you're building the right thing before you've spent a year finding out you weren't.
And measure honestly. Not just output: features shipped, code written, tasks completed. Measure what changed for your customers. That's always been the harder question. AI doesn't make it easier.
The organizations that are going to do this well aren't the ones moving fastest. They're the ones that stay honest about what they're actually learning.
This post draws from a recent episode of Definitely Maybe Agile with hosts Peter Maddison and Dave Sharrock. Listen to the full episode here or find us at definitelymaybeagile.com.