👋 Hey {{first_name|there}},
Your engineers are shipping more code than ever, your AI adoption numbers look great in the board deck, and somehow, the features your customers asked for in Q1 are still not out. The speed is real. It's just landing in the wrong place.
📉 Where it's costing you
A VP of Engineering told me last month that her team's pull request volume was up something like 60 percent year over year. Then, almost as an afterthought, she added that the lead time for changes hadn't really moved. Same features, same quarter, same slips. She'd spent a real chunk of the budget on coding assistants, and every dashboard pointed up. The one number the CEO cared about time from idea to customer satisfaction.
This is the pattern now, and the data backs it up harder than I expected. Faros AI's 2026 telemetry across roughly 22,000 developers found output per engineer climbing while median PR review time went up several-fold, and incidents per change climbed right along with it. The 2025 DORA report, with around 5,000 respondents, ends up in the same uncomfortable spot: AI lifts throughput and, at the same time, tends to hurt stability. You're pushing more changes, faster, into a system that was never built to absorb them.
Here's the part nobody wants to say in the all-hands. Writing code was rarely your constraint. We covered this from the delivery side back in the 48-hour bottleneck audit and again when we mapped lead time versus cycle time. AI made the cheap stage cheaper. But the expensive ones review, integration, testing, and the plain wait for a human to make a call are right where they always were. Now they just have more work piling up against them.
🧭 The reframe
Most leaders think: AI makes the team faster, so delivery gets faster.
What's actually true: AI makes code generation faster, which just relocates the bottleneck to whatever stage comes next.
There's a study people keep citing, the METR randomized trial from mid-2025, where experienced developers expected AI to speed them up by around 24 percent and instead came out roughly 19 percent slower on the tasks measured. Small sample, open-source work, so I wouldn't treat it as gospel for your org. But the direction matches what the larger datasets show and, honestly, what you can feel walking the floor: the typing was never the hard part. Review is. Knowing whether the change is right is. Getting it safely to production is.
So when you pour AI into the part that was already fast, you don't shorten the line. You move the crowd to a different window. And if the only thing you're watching is that fast window code volume, acceptance rate, and commit counts, the metrics look terrific while delivery quietly stalls behind them. That gap between the dashboard and the actual quarter is what your board is starting to ask about.
🔬 The lens: Where Did the Bottleneck Go?
A five-question read on whether your AI spend is hitting the actual constraint.
Has the lead time for changes actually dropped? Not PR count, not lines, not acceptance rate. Idea to customer. If that number is flat while output is up, your constraint is downstream of coding, and AI didn't touch it.
What's your PR review wait time, and where is it trending? If engineers generate faster than reviewers can absorb, you've built a queue, not a pipeline. A bad answer here is "we don't track it."
Is the change-failure rate climbing with volume? More changes through the same testing and review gates usually mean more escapes. Rising incidents per change are the instability tax showing up on a different invoice.
Where do changes actually wait? Walk one feature end-to-end and timestamp every handoff. The longest wait is your constraint. I'd bet it isn't the keyboard.
Are you measuring the fast stage or the slow one? If your AI dashboard reports generation metrics and nothing about review, integration, or deployment, you're admiring the part that was never the problem.
Run this against your own org before you read on. Most leaders already know which question stings.
🔍 What this looks like in a real org
Situation: A Series B SaaS company, maybe 40 engineers, rolled out coding assistants across the board. Leadership expected a meaningful jump in delivery within a quarter.
What looked fine: PR volume up sharply, developer satisfaction with the tools high, adoption near universal. The rollout looked like a win.
What was actually happening: Senior engineers were now spending most of their day reviewing a flood of AI-assisted PRs from the rest of the team. Review became the full-time job nobody was hired for.
They walked one feature end to end. Coding: a day and a half. Waiting for review: nine days.
The constraint was never code. It was a senior engineer's review capacity, and AI had quietly tripled the load on it.
The hard part: there's no clean fix. Throwing AI at review quality is dicey; AI-assisted review tends to wave through AI-generated mistakes. Hiring more seniors is slow and expensive. They ended up reshaping who reviews what and capping how much in-flight work each person could hold, which helped, but it wasn't a dashboard you could turn green in a sprint.
What it changed: once the review was the explicit target instead of code volume, lead time finally started to move. Took about two months to show up in the numbers. The AI spend didn't pay off until they pointed it out, and their attention was drawn to the real constraint.
🎯 If you lead a team, do this
Pull the lead time for changes and PR review wait time for the last two quarters. Put them next to your AI output metrics. If output rose and lead time didn't, you have your answer.
Walk one real feature end-to-end with timestamps on every handoff. Find the longest wait. That's where your next dollar should go, AI or otherwise.
Stop reporting code-generation metrics to leadership on their own. They flatter the wrong stage, and they'll cost you credibility when the quarter doesn't match.
This week, the one thing worth doing: find your single longest handoff wait, and decide whether anything you've bought in the last year actually shortened it.
👋 The takeaway
AI didn't make your team faster. It made one stage faster and moved the crowd to the next window down the line.
Measure the stage AI speed up, and your dashboard will look great right up until someone asks why the roadmap slipped. Measure the slow one instead.
Small ask: Hit reply with one line: where does work actually wait longest in your org? I read every reply.
Thanks for reading.
See you next week,
Bogdan Colța
Tech Architect Insights