Adoption isn't a result

Slide four of the quarterly review. AI adoption, 78% of engineers active weekly, 41% of merged code AI-generated, both numbers up and to the right with a green arrow beside them. The room nods. Somebody says the word momentum.

Slide eleven has the delivery numbers on it. They're flat. Nobody in the room connects slide four to slide eleven, partly because eight slides is a long way, and mostly because the two slides belong to different people and only one of them is having a good quarter.

Every number on slide four is a utilisation metric. Your org already knows what those do to you, in every other context, and has known for years.

What utilisation always did

Utilisation measures how busy a resource is. It says nothing about whether work is reaching a customer, which is why an org that books its engineers to 100% is reliably slower than the one that stops at seventy. The queue does the damage, and the queue is invisible on a utilisation chart by construction.

Adoption rate is that same instrument pointed at a new resource. It tells you how busy the generation step is. It tells you nothing about the step immediately downstream, which is still staffed by the same number of people it was staffed by last year, and which is now where all of your lead time lives.

The uncomfortable version: if generation goes up and nothing else changes, adoption and delivery aren't just uncorrelated. They move apart.

The numbers are already in

This isn't a prediction any more, which is new this year.

CircleCI's 2026 delivery report puts feature-branch throughput up 59% year over year while main-branch throughput for the median team actually fell, by about 7%, with main-branch success rates down to 70.8%. Work is being produced much faster and arriving on the branch that matters slightly slower.

Faros AI's telemetry across roughly 22,000 developers has median code review time up 441.5% against a 33.7% rise in task throughput. Same report: PRs merged with no review at all up 31.3%, and the production incident ratio up 242.7%. LinearB, looking at 8.1 million pull requests, has AI-assisted changes at 400-plus lines at the 75th percentile against 157 for unassisted ones, waiting 16-plus hours for a reviewer where an unassisted change waits about 200 minutes.

Read those together and it's one finding stated four ways. Bigger units of work, arriving faster, at a review step that didn't grow, so they wait, and a growing number of them stop waiting by going through unread.

That last part is the one worth sitting with, because it's what a mandatory review policy looks like when it meets volume. The rule didn't hold. It just stopped being visible.

Why adoption became the number anyway

It's countable on day one, which almost nothing else in this is. It moves quickly, which makes it satisfying. It arrives free in a vendor dashboard, so nobody has to build anything. And it has no enemy: high adoption makes the engineering leader look decisive, the tooling team look effective, and the finance conversation look settled, all at once.

There's also a legitimate use hiding in there, and this piece falls apart if it doesn't say so clearly. Adoption fails as a result and is entirely real as a constraint. Those aren't the same claim and only one of them is being attacked here.

Low adoption genuinely blocks you, and the reasons are usually specific and fixable: the tool doesn't have access to the repo, nobody's said out loud that using it is allowed, or the senior engineers have decided it's for people who can't code and everyone junior has noticed. An org in that position has adoption as its binding constraint, correctly, and should be working on it rather than on anything downstream. That was the first year of this for a lot of teams, and it was the right year to have.

What doesn't follow is the other direction. High adoption proves nothing at all. A number that tells you where you're stuck when it's low, and tells you nothing when it's high, is a diagnostic, and diagnostics get retired once they've done their work.

Fine. Measure it for six weeks, fix what it surfaces, then delete the metric.

Nobody deletes the metric. It goes on a dashboard, then into a board deck, and eighteen months later a team is being asked why their adoption is 64% when the company average is 78%, which is the point at which the number starts actively producing bad work.

What goes on the slide instead

Start with one number, because everything else on this list is downstream of it and most orgs skip straight to the downstream ones.

Deployments to production. If your deploy count is flat, you have not gone faster, and something in your pipeline is bottlenecked no matter what any other chart says. PR volume, time to first review, cycle time on the coding step: all of those can improve while this one sits still, and when they do, what you've learned is where the queue moved to, not that anything reached a customer. It's the cheapest honest instrument available and almost nobody leads with it, because it doesn't flatter the step that got faster.

Then the rest, which are refinements of the same question. High performance is shipped outcomes per unit of organisational attention, and that definition doesn't change because the generation step got cheap.

Time from intent to production, meaning the moment somebody decided this should exist to the moment a customer had it. Not PR cycle time, which is the segment that got faster and the reason the rest of the picture is hiding.

Share of change that never needed a person in the review queue at all. This one goes up only if you've done real work on blast radius and test honesty, which is exactly why it's a better number than adoption.

Pickup time on the changes that do need a person, because that's where the loss actually sits, and it's the number that told CircleCI's median team something their throughput chart didn't.

Escape rate and incident ratio, watched hard, and held flat while the first three move. If they climb, you're not shipping faster, you're shipping sooner and paying later.

And cost per merged change, which is the one nobody had to think about when compute was a rounding error and which is now a live engineering number.

Notice that none of the five mention AI. That's deliberate, and it's the whole argument. If the tooling is working, these move. If only the input numbers move, what you've bought is a larger queue with better tooling in front of it.

The objection, which is fair

Your board wants evidence that the company is adopting AI. Real constraint, not a silly one, and refusing to answer it is a way of losing an argument you could win.

So answer it once. Adoption is a rollout milestone with a date on it: we got to 80% weekly active by March. Milestones get reported when they're hit and then retired. Every report after that puts a delivery number beside it, and the honest sentence is short. Generation is up this much, this is what reached customers, this is what it cost, this is what broke.

The harder version of that conversation is the one worth preparing for. If two quarters go by and no delivery number has moved, the answer isn't that the tools underperformed. It's that generation was never your constraint, and the org has just paid a lot of money to speed up a step that wasn't the problem. That's a finding. Report it as one, then go and look at where the work is actually waiting, because it's been waiting there since long before any of this.