Author(s): The AIExplorer

Originally published on Towards AI.

A founder I was talking to last quarter pulled up his engineering dashboard on a video call, practically beaming. Commit volume up. Pull requests up. Everyone on Copilot, Cursor, or Claude. Then I asked how many of those PRs had actually shipped to production that month. He went quiet, clicked around for a minute, and said, “Huh.”

That “huh” is the whole story of engineering productivity in 2026.

Every dashboard I’ve seen this year tells the same lie by omission. Teams are writing more code than they ever have. What most leaders haven’t checked is whether any of it is getting out the door. And when you check, the answer is often uncomfortable.

The Dashboard That Looked Great (and Was Lying)

Here’s what’s actually happening across the industry, not just at the one client. CircleCI’s 2026 State of Software Delivery report, drawn from more than 28 million CI/CD workflows, found that average daily workflow runs jumped 59% year over year, the biggest single-year throughput increase the report has ever recorded. AI clearly changed something.

But the same report found that for the median team, feature branch throughput rose 15% while main branch throughput actually fell. More code going in. Less making it out. The top 5% of teams nearly doubled their output, while the bottom quartile saw no real gain at all. AI didn’t lift everyone. It widened the gap between teams that already had solid delivery systems and teams that didn’t.

I’ve watched this play out with a startup client whose engineering team went all-in on AI coding assistants around the same time. Commit velocity looked fantastic in the monthly board deck. Meanwhile the actual release cadence slowed, because every one of those AI-generated PRs still had to pass through the same two reviewers who’d been doing code review the old way for three years. Those two reviewers didn’t get faster just because the code arrived faster. If anything, each PR took longer to review, because more of it needed checking for the kind of confident-sounding mistakes AI tools are good at producing. The bottleneck didn’t disappear. It just moved.

Sound familiar? If your team adopted AI tools and your velocity numbers went up while your gut feeling says things got messier, you’re not imagining it. You’re looking at the same pattern showing up everywhere.

How to Measure Developer Productivity With AI Coding Tools

This is the part where most CTOs reach for the wrong fix: they buy another AI tool to write code faster, when writing code was never the constraint. The constraint moved downstream, to review, to testing, to whatever gate separates “written” from “shipped.”

Kent Beck put it better than I could, in a piece on what he calls programming deflation: “When anyone can build anything, knowing what’s worth building becomes the skill.” I’d add a second half to that sentence for anyone running an engineering org right now. Knowing what’s safe to ship is the other skill, and nobody budgeted for it.

So how do you actually measure developer productivity with AI coding tools in the mix, instead of just measuring how much code got typed? You stop treating throughput as a single number and start splitting it by where it happens in the pipeline. Feature branch activity tells you how fast your team can experiment. Main branch activity tells you how fast your team can deliver. Those two used to move together closely enough that nobody had to separate them on a dashboard. They don’t move together anymore, not since AI made the experimenting part nearly free. The gap between the two lines is the most honest signal you have, and it’s one most tools still bury inside a single “velocity” chart.

The Pragmatic Engineer’s 2026 survey of over 900 engineers found something that lines up with what I’m seeing directly: management at most companies isn’t tracking this gap at all. One lead engineer told the survey, describing what’s happened to code review at their company: “I used to do very deep code reviews where I’d take the time to understand the architecture and provide feedback on maintainability. I have no motivation in spending that time to review a giant PR where it’s clear even the original author didn’t bother to do that.” That’s not a productivity gain. That’s a debt getting quietly rolled forward.

Where the Bottleneck Actually Moved To

I want to be precise about this, because it’s easy to hear “AI creates messy code” and file it under generic AI skepticism. That’s not quite it. The actual finding, echoed across the CircleCI data and the Pragmatic Engineer survey both, is that AI amplifies whatever engineering culture already existed before it showed up. Teams with strong tests, clear architecture, and real code review got faster and stayed clean. Teams without those things got faster and messier, at the same time, from the same tool.

That is not a comfortable finding if your team was already a little loose on process. It also means the fix isn’t “use AI less.” It’s “fix the thing AI just made visible.”

A concrete industry benchmark worth putting on your own dashboard: main branch success rate. The healthy target is around 90%. The current industry average sits at roughly 71%. That gap, not your commit count, is where the AI productivity story actually lives for most teams right now.

The Numbers Worth Actually Putting on a Dashboard

Commit count and PR volume are the easiest numbers for AI to inflate without anyone getting more value out of it. They’re also the metrics that make a board slide look good, which is exactly why they survive so long after they stop meaning much. If I were rebuilding a client’s engineering dashboard from scratch this year (and I’ve done exactly that more than once), here’s what would replace vanity throughput.

Main branch success rate, tracked separately from feature branch activity, because a rising feature branch number next to a flat main branch number is a specific, fixable diagnosis. That’s an integration problem, not a writing-code problem, and the fix looks completely different depending on which one you actually have.

Mean time to recovery, because it’s the number that tells you what happens when an AI-assisted change breaks something. Nobody markets this one. It’s where the uncomfortable truth actually lives.

Review depth, even if it’s just a rough proxy like time-per-PR or comments-per-PR. Not to punish reviewers, but because “review happened” and “review meant anything” are different claims, and right now most orgs can only prove the first one. A five-minute approval on a five-hundred-line AI-generated diff is a data point worth looking at, not celebrating.

None of these are exotic. They’re metrics that mattered before AI too. The difference is that in an AI-assisted pipeline, ignoring them costs you faster and more quietly than it used to. Do you actually know your own team’s main branch success rate right now, off the top of your head? If not, that’s worth finding out before the next retro, not after.

What Good Actually Looks Like

Here’s the part I don’t want to leave out, because naming the problem and stopping there isn’t useful to anyone. The teams pulling ahead in the CircleCI data weren’t the ones being cautious about AI. They were the ones who treated validation, tests, review standards, deployment gates, as seriously as they treated the AI tooling itself. Small teams did it by staying lean enough that nothing slipped through unnoticed. Larger, well-resourced teams did it by actually investing in the delivery infrastructure to match the new volume.

Neither approach requires slowing down your engineers or telling them to stop using Copilot. Writing code faster was never the finish line. It was always table stakes, and AI just made that a lot harder to hide from.

The founder from that first call did fix it, eventually, though “fix” undersells how unglamorous it actually was: two more reviewers, a hard rule that nothing merges to main without passing the existing test suite, and a monthly look at main branch success rate instead of PR count. Nothing about that story would make it into a slide deck. It worked anyway.

If your engineering metrics still say things are going great and your gut says otherwise, trust the gut long enough to go check. The dashboard usually catches up.

If you’re trying to figure out whether your engineering team’s AI adoption is actually paying off, or just generating more code to review, that’s the exact kind of gap Agively gets called in to look at. You can see how we approach it at agively.com.

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI