Everyone's talking about the AI software delivery bottleneck like it's obviously the coding step. AI writes code faster. So teams ship faster. So everything gets better. That's the theory going around. It's also missing the point.
Dave and I got into this on a recent episode. It kept circling back to one thing. Coding was never really the bottleneck. It just used to be slow enough that nobody noticed what was actually holding things up underneath it.
The Two Problems Nobody Solved
Before AI, a feature might take three weeks to build. You could tell yourself the three weeks were the cost of doing business. Now the same feature might take three hours. That excuse is gone. What's left are two questions that were always the hard part.
Do we actually know if the thing we built is valuable? And do we know what we should build in the first place?
Neither question has anything to do with typing speed. You can answer them slowly with a slow team. You can answer them slowly with a fast one too. Making the middle bit, the actual writing of code, go faster doesn't touch either question. It just means you find out you don't know sooner.
Why the Bottleneck Keeps Moving
There was a similar moment a while back. People said pull requests would become the constraint once coding sped up. That didn't really hold either. The constraint keeps moving. It lands back on the two questions that were always sitting there. They were mostly ignored because they were never the loudest problem in the room.
We dug into this same pattern in The Bottleneck Didn't Disappear. It Moved. It looks at what happens once AI clears one constraint and the next one just picks up the slack.
Sprint Length Was Never About the Coding
A lot of teams get this backwards. For years, the pushback on sprint length has gone one direction. Teams want it longer. Give us three weeks instead of two, they say, because the system is complex and two weeks isn't enough.
Dave made a point that stuck with me. Sprint length was never really about how much you can produce. It's about how long you can go before finding out you're headed in the wrong direction. Spend two weeks chasing the wrong objective, and you throw away two weeks of work. That's the actual cost you're managing. Not the coding effort.
The right length for a sprint isn't a coding question at all. It's a question about how fast your organization can learn something, then decide what to do with it.
I keep coming back to a comparison Dave made about kids and homework. A kid rushes through an assignment, throws it down, and says "done, heading out." Doing it fast doesn't mean it's any good. You still have to sit down and look at the part that actually matters. Is this valuable? Are we even solving the right problem? That review step was never about speed. AI hasn't changed that part of the equation at all.
More Code Isn't the Same as More Value
Here's the part that should worry people more than it does. Surveys and internal telemetry right now show more code being written and more deployments going out. The actual business value being generated is still hard to point to. This is the AI software delivery bottleneck hiding in plain sight. Activity goes up. Outcomes stay flat.
That tracks with something I said on the episode. Shipping more code can just mean shipping more bugs. More edge cases. More places where dependencies between systems start to conflict. None of that gets solved by writing faster. If anything, it's a reason to slow down and think harder about what you're building before you build more of it.
Dave has made a related point before: most delivery issues trace back to measuring activity instead of value. AI just makes the activity easier to produce.
The Cost of More Options
The instinct right now is to treat AI as an optimization play. Do the thing you were already doing, just faster. But the real value shows up somewhere else. It's in the extra room AI creates for things teams never had time for before.
Scenario planning is a good example. The old lean idea of deferring commitment, holding two or three options open and only committing once you have enough information to make good decisions, was always smart. Almost nobody had the bandwidth to actually do it. Now some teams do.
That comes with its own cost though. Instead of choosing between option A and option B, a stakeholder is suddenly looking at options A through E. More choice doesn't automatically mean a better decision. A leader now has to explain why option C won. They have to build confidence that the recommendation isn't a misread of the situation. And they have to do that with people who weren't in the room for the tradeoffs. That's a heavier conversation, not a lighter one.
Judgment Doesn't Speed Up as Easily as Output Does
Here's the part I find genuinely interesting. What happens to decision-making once everything upstream of it gets faster?
Say an AI agent hands a product owner a report at the end of the day. It reads "here are the calls I made on your behalf." How much do you trust that? Most of us already nod along to language model recommendations. There are simply too many decisions to scrutinize each one properly.
Dave brought up ER physicians in that conversation. It's a comparison worth sitting with. Doctors in an emergency room make fast, high-stakes calls with limited information, constantly. But that ability comes from years of deliberate training, structured decision heuristics, and repeated exposure. Nobody hands a new physician that judgment on day one.
Most leaders being asked to make faster, higher-stakes calls haven't had anything close to that kind of preparation. My honest reaction, when someone tells me to decide quickly, is still to ask for a minute to understand what's actually changed.
That instinct isn't wrong. It's a sign we've built faster tools for generating options. We haven't built the judgment to match the pace those options now arrive at. Dave wrote about this shift directly in When Thinking Isn't Just Fast or Slow Anymore: The Rise of System 3.
What This Means for Your Team
If your organization measures AI's impact by lines of code, deployment counts, or how quickly tickets close, you're measuring the wrong thing. You're tracking the part that was never the real constraint. The AI software delivery bottleneck isn't there. It never was.
The questions worth asking are less comfortable. Do we know whether what we shipped mattered? Do we understand what we should build next? When a decision needs to happen fast, do the people making it have the context, and the training, to make it well?
None of that gets solved by a faster model. It gets solved by paying attention to the parts of the system that were always the hard part. The parts AI just made impossible to keep ignoring.
This post draws from a recent episode of Definitely Maybe Agile with hosts Peter Maddison and Dave Sharrock. Listen to the full episode at definitelymaybeagile.com.