A CEO called me last month, frustrated. His engineering team had just adopted three new AI tools. Throughput numbers were up across the board. And yet the release his biggest customer was waiting on had slipped for the third time. “I don’t understand,” he said. “The numbers say we’re faster than we’ve ever been.”
He wasn’t wrong about the numbers. He was looking at the wrong ones.
The Numbers That Should Worry You
CircleCI’s 2026 State of Software Delivery report analyzes more than 28 million CI/CD workflows across 22,000 organizations. The headline looks great: average engineering throughput is up 59% year over year, the largest increase since the report began in 2019. AI-assisted development is producing more code, faster, than anyone predicted.
But here’s what the same data reveals when you look past the headline.
Main branch success rates sit at 70.8%, the lowest in five years. The benchmark is 90%. That means nearly 3 out of every 10 attempts to merge code into production are failing. Recovery times are climbing too. Seventy-two minutes on average to get back to green, up 13% from last year.
More code is entering the pipeline. Less of it is reaching your customers.
Where the Speed Actually Disappears
If you’re a CEO looking at a velocity dashboard and seeing green, you’re looking at the wrong part of the system. The throughput gains are real, but only on feature branches, where developers experiment and iterate. That’s the part of the pipeline where AI accelerates most visibly.
But feature branch throughput and main branch throughput tell you two different stories. The median team shows feature branch activity climbing while main branch throughput actually declines nearly 7%. Your developers are writing more code. Your delivery system isn’t absorbing it.
Your developers aren’t the bottleneck. The bottleneck is the review queues, the approval chains, and the release management process that nobody has revisited since before you adopted AI.
Review queues are longer because there’s more code to review. Integration failures are more frequent because AI-generated code arrives faster than your validation systems can process it. Release decisions that once happened naturally now pile up because nobody has redesigned the decision loops for this volume.
This Isn’t a Technical Problem. It’s a Decision Architecture Problem.
Here’s what I see in company after company navigating this exact challenge: the delivery system is designed for a pace that no longer exists.
Your review cadence is set for a world where developers push a handful of changes a day, not dozens. Your release governance is built for a world where the bottleneck is writing code, not validating it. Your decision loops (who approves what, how quickly, with what information) have never been stress-tested against this kind of throughput.
AI doesn’t create these cracks. It just makes them load-bearing.
Think of it this way. You double the output of every machine on the factory floor. But you don’t add quality inspectors, retool the assembly line, or redesign the shipping dock. The machines are running faster than ever. Product is piling up between stations. And your dashboard is telling you productivity is up.
That’s exactly what’s happening inside your engineering organization.
The Cost You’re Not Calculating
The CircleCI data makes the financial exposure concrete. At a 70% success rate, a team pushing five changes a day experiences roughly 1.5 deployment failures daily, compared to one every two days at the 90% benchmark. Even if that team recovers in 60 minutes each time (faster than most), the math adds up to roughly 250 additional hours lost per year. Scale that to 500 daily changes and you’re burning the equivalent of 12 full-time engineers just getting back to green.
That’s not a rounding error. That’s lost revenue your board can see every quarter.
But that’s only the math you can measure. Every failed deployment doesn’t just consume engineering hours. It delays the features behind it. It erodes confidence in release dates. It makes your team conservative about shipping, which is the opposite of what you bought AI tools to achieve.
You’re paying for speed to value. You’re only getting additional activity.
What the Top Performers Do Differently
The same report reveals something important about the teams that are actually converting AI throughput into shipped software. Fewer than one in twenty teams manage to scale both code creation and delivery simultaneously. Those top 5% teams nearly double their throughput while maintaining a 90% main branch success rate and recovering from failures in under two minutes.
They don’t achieve that by writing better code. They achieve it by redesigning the systems around the code. Their feedback loops are tighter and their validation workflows run faster because they’ve invested in the decision architecture, the review cadences, integration gates, and release governance, that lets high-volume throughput actually flow instead of backing up.
The most effective teams redesign their decision loops before AI overwhelms them.
What This Means for You
You don’t need to understand CI/CD pipelines to act on this. You need to understand that your delivery system is a decision system, and right now, it’s likely running on architecture designed for a slower world.
Three questions worth asking your CTO this week:
→ What’s our main branch success rate?
If they don’t know the number, that’s the first problem. If it’s below 90%, the delivery system is under strain, and adding more AI tools will make it worse, not better.
→ Where are decisions backing up in our release process?
Code reviews, integration approvals, release sign-offs. Somewhere in that chain, decisions are queueing faster than they’re being made. That’s where your speed is disappearing.
→ What would it take to redesign our decision loops for the throughput we have now, not the throughput we had two years ago?
This isn’t a six-month initiative. It’s a conversation about cadence, governance, and how quickly your organization can make good decisions at higher volume.
The Real Question Behind the Dashboard
AI is doing exactly what it promised. It’s compressing the creation cycle. Your developers are more productive than they’ve ever been. The tooling works.
What isn’t working is the organizational architecture that sits between creation and delivery. The decision loops, the review bottlenecks, the release governance. The parts of the system that are invisible when throughput is low enough to absorb the friction.
The dashboard says velocity is up. Your revenue timeline says otherwise. The gap between those two numbers is a decision architecture problem, and it’s costing you quarters, not days.
The companies that figure this out first won’t just ship faster. They’ll ship with the kind of predictability that lets you make promises to your board and keep them.
The fix isn’t more tools. It’s redesigning how your organization makes decisions at speed.
Kathy Keating is a systems strategist and Board-Certified Director who helps CEOs close the gap between engineering activity and business results. A CTO who has led through the challenges she writes about, she works with scaling companies to redesign the decision architecture, operating rhythms, and leadership systems that turn technology investment into predictable delivery. She is co-author of Liquid:How CEOs and CTOs Unlock Flow & Momentum in Complex Systems. Learn more at kathkeating.com.
