Your engineers are coding faster than ever. AI tools have boosted average throughput by nearly 60%. Commits are up. PR counts are up. Your team feels productive and the metrics you’re tracking show more output from each engineer as well.

So why is less shipping to production?

This is the quiet crisis sitting in the middle of a lot of engineerings orgs right now and most leaders aren’t seeing it because the metrics they’re watching only tell half the story.

As an engineering leader, I’ve seen the shift when a team stops building to close out Linear tickets and starts building for real customer needs.

AI has supercharged your team. Code gets written faster. Reviews move quicker. Everyone looks busy, output is high, and the numbers your dashboard shows are trending up.

So the system is working.

New data from engineering analytics platforms tells a more complicated story.

AI-assisted development has driven a 59% increase in average engineering throughput on feature branches. That’s real. That’s significant.

But main branch throughput - code that actually ships - declined by 6.8% for the median team.

More code. Fewer releases.

The bottleneck didn’t disappear when you gave everyone a coding copilot. It moved. AI accelerated the front of your delivery pipeline without touching the back of it. Integration, review, testing, deployment, recovery, those are still running at the same pace they were before.

Think about your delivery pipeline in two distinct segments:

Code velocity — speed from idea to a working feature branch. This is where AI wins. This is what most productivity tools measure and market. Your developers feel this every day.

Release velocity — speed from branch to production and stable. This is where the value actually lands. This is where most teams are now falling behind.

When these two speeds diverge, you get a specific set of failure modes:

The worst part: most dashboards show the first number. Very few show the second.

Two numbers belong on your dashboard right now if they aren't already:

Main branch success rate. This is the percentage of CI/CD pipeline runs on your main branch that pass all checks and complete cleanly — tests, builds, deployments, all of it. Every failed run is a blocker: someone has to stop, investigate, fix, and re-run before the next merge can safely land. At scale, a low success rate creates a queue of blocked engineers and a compounding backlog of code waiting to ship.

It's calculated simply: successful main branch pipeline runs divided by total runs. You're almost certainly already tracking this in GitHub Actions, CircleCI, or wherever your pipelines live — you may just not be watching it as a leadership metric.

The industry benchmark is 90%. The current average is 70.8%. That means the median team is failing nearly 3 in every 10 pipeline runs on main. If yours is below 85%, your delivery system is creating real drag — regardless of how good your code velocity looks.

Mean Time to Recovery (MTTR). When something breaks in production, how long does it take to get back to stable? AI-assisted development raises code volume and, often, incident frequency. MTTR is where your productivity gains either hold or evaporate. A team that ships fast but recovers slowly isn't actually shipping fast — they're just failing faster.

These aren't just reliability metrics. They're productivity metrics. They tell you whether the throughput your team generates is actually reaching users.

You don't fix this by slowing down AI adoption. You fix it by building the delivery infrastructure to match your new code velocity.

Start with an honest audit. Look at the ratio of code committed to code deployed over the last 60 days. If there's a growing gap, you have a delivery bottleneck. Name it explicitly with your team.

Treat your main branch health like a team SLA. Make main branch success rate visible. Review it in your weekly engineering sync. When it drops below threshold, treat it like an incident — not a footnote.

Invest in the boring parts of your pipeline. Testing, CI speed, deployment automation, incident response runbooks. These aren't exciting. They're also the reason your AI investment pays off or doesn't. The teams seeing the highest end-to-end gains from AI are the ones who paired AI adoption with platform investment.

Watch for integration accumulation. Long-lived feature branches are a symptom, not a cause. If engineers are sitting on branches for more than three to four days regularly, your integration cadence can't absorb the volume AI is producing. That's a structural problem worth addressing directly.

Every engineering leader is navigating the same pressure right now: adopt AI quickly, show productivity gains, move fast. That pressure is real and not going away.

But the leaders who come out ahead aren't the ones who just handed everyone a coding assistant. They're the ones who recognized that AI changed the shape of the problem — and then built the infrastructure, culture, and measurement systems to match.

Code velocity gets the headlines. Release velocity is how you actually win.

You don't have to choose between them. But you do have to build for both.

Pull two numbers for your team this week — main branch success rate and MTTR. Not a rough estimate. The actual numbers, from your actual tooling (GitHub Actions, CircleCI, PagerDuty, Incident.io — wherever they live). If you can't get to them easily, that's your first problem to solve.

Once you have them, ask yourself:

If the answer to any of those is no, you have a visibility problem before you have a delivery problem. Fix the visibility first. And when you talk about "productivity" with your team — make sure you're measuring code velocity and release velocity. They are not the same conversation.

Want something covered? Hit reply and tell me. I love hearing what you’re dealing with.

📬 Reply back to this email to book a 30 min session (free for subscribers!)

Fast code is table stakes. Shipping it reliably is the actual job.🚀

Until next time,
Sabeen 🐝

P.S. The stats in this article come from CircleCI's 2026 State of Software Delivery report — 28 million+ workflows analyzed. If you want the primary source, it's worth a read. And if you're new here, welcome 👋 — every issue is one clear framework you can use with your team this week.