Nobody got slower. Everything did.

Your engineers say AI is working. Your dashboard says it isn't. Both are right.

You know this meeting.

Your CTO wants a number for the board. Your engineers tell you, credibly, that coding agents have changed how they work. Your platform team has the telemetry to back it up — adoption is high, token spend is real, people are shipping.

And your delivery dashboard is flat. Or up a few percent, which is worse, because a few percent is what you'd get from a good quarter anyway.

So you're stuck between two true things, and the temptation is to pick one: either the engineers are experiencing a novelty effect, or the metrics are too crude to see what's happening. Most organisations quietly pick the second, stop looking, and go back to reporting adoption.

There's a third explanation, and it's the one we keep running into. It's not that the gains aren't real. It's that something is eating them on the way to the number you report — and it doesn't show up on any chart you currently have, because every individual chart looks fine.

The thing you're not measuring

Draw the path a change takes through your organisation:

task started → branch → pull request opened → review → merge → production

Now ask which of those segments you can actually report on.

Almost everyone has excellent data on one: branch to PR. That's where the agents work, so that's where the instrumentation went. PR sizes, complexity, token cost per session, commit characteristics.

After that it's usually one undifferentiated number — "lead time" — covering review, rework, approval and release as a single block. And the segment before, from ticket to first branch, is typically invisible, because measuring it means joining git data to your issue tracker. That's harder than it sounds. It depends on ticket hygiene being good enough to trust, and hygiene varies enormously between departments in the same company.

So you instrumented the part you expected to improve, and left the part where the improvement has to survive as a black box. That's not negligence. It's just what happens when the tooling arrives faster than the measurement.

Two things that are both true

We've been comparing notes with engineering leaders at large European organisations — both well past the pilot stage, both with thousands of engineers.

At one, the platform team has tracked AI's effect on their codebase for two years. They know two things:

Pull requests keep getting bigger. The heavy buckets — 500 to 1,000 lines, 1,000 to 2,000 — have been growing steadily with each capable model release. They see the same fingerprint inside the code: complexity inflection points that line up with agent adoption. Their plain-language conclusion: teams who get carried away end up with pull requests that discourage reviewers and slow delivery.

Their best delivery win came from automating approvals. They built a bot that classifies PRs by rollout risk; roughly a third come out low-risk and get auto-approved. That cut lead time to merge by 20 to 40 percent.

Sit with that for a second. The biggest measurable delivery improvement didn't come from AI writing the code. It came from AI approving it. The gain landed in review, not implementation.

Meanwhile the implementation side is producing bigger units of work, structurally slower to review. Both facts are theirs, both are solid; they just live in different decks.

The number that changes the conversation

At the second organisation, the engineering-productivity lead went and checked his own merge request data — hundreds of thousands of MRs, more than a year of pre-AI baseline. He found three things:

• MR size is rising.
• Size predicts lead time almost perfectly. Bigger is slower.
• Lead time is falling in every single size class — XS through XXL — whether he looks at production-linked repositories or everything.

Point three looks like it kills the whole thesis. Everything's getting faster. What leak?

But hold all three at once and you've got two forces pulling against each other:

• Inside each size class, work is moving faster. Review is improving, tooling is improving, people are getting better at this.
• Across classes, volume is migrating toward the classes that were always slow.

Your headline number is the net of those two. It tells you who's winning, and nothing about how big either one is. You can be making real progress and shipping a flat number. You can also be making no progress and shipping a good number, if the mix happens to move your way.

What it costs, in a spreadsheet you could build this afternoon

Invented numbers, to show the shape. Every class gets 25% faster. The mix drifts modestly toward bigger changes.

Weighted average goes from 21.0 h to 18.7 h. That's an 11% improvement. It's what your dashboard shows, and it's a perfectly decent quarter.

Now run it again with this year's speeds and last year's mix — what would have happened if the shape of your work hadn't changed. You land at 15.75 h. A 25% improvement.

The process improvement was worth 25 points. Eleven reached the board. Fourteen points went to the drift in what you ship — and not one team got slower, and every chart underneath still looks like a win.

Call it the drift tax.

To compute yours you need two periods, and for each size class: its share of volume and its average lead time. Ten rows. The gap between "what each class achieved" and "what the overall number shows" is your tax. (This is a standard technique — demographers have used it since the 1950s to separate "people got healthier" from "the population got older." Same arithmetic.)

Why this is worth your afternoon

Three decisions change depending on the answer.

What you tell the board. "Lead time improved 11%" invites the obvious follow-up: that's within noise, what did we buy. "Our process improved 25%; 14 points were absorbed by larger change sizes, and here's what we're doing about it" is a different conversation. The second version survives scrutiny because it names its own bad news.

Whether to fight about PR size. Right now that argument is tribal. Some of your teams believe in small PRs; others think it's bureaucracy. Nobody has a number. The drift tax gives you one — and it might come back small, in which case stop arguing and go work on something else.

Which teams to copy. If you're trying to find the teams doing this well, the drift tax tells you where to look: the teams whose within-class improvement is high and whose mix hasn't drifted. Those are the ones who figured out something transferable. Teams with the best raw numbers are usually just the teams with the youngest codebase.

Three ways your dashboard might be lying to you

Before you trust any downward trend in lead time, rule all three out. Each takes minutes; each can invalidate the whole picture.

You're filtering on close date. If your date window uses when a change closed, then recent weeks structurally exclude everything still open — and what's still open is the slow stuff. This produces an apparent improvement in every class at once, which is indistinguishable from a real one. Check which date dimension your period filter sits on. This one bites more teams than any other.

Your buckets move. If XS through XXL are percentiles recalculated each period, then "faster in every class" is partly true by construction — the boundaries slide along with the distribution. You need fixed line thresholds for any of this to mean anything.

Your clock starts in the wrong place. Lead time from first commit is unreliable in any rebase-heavy workflow: rebasing rewrites history and collapses commits toward the merge point, turning a two-day segment into an hour. If you want a start point earlier than PR creation, anchor on the ticket instead of the commit. Bonus: that also catches work spanning several repositories, which commit-based measurement drops entirely.

Bigger PRs aren't automatically the problem

Resist the obvious conclusion. "Mandate smaller PRs" is a policy, and policies against engineers' judgment have a poor record.

One team we've talked to went deliberately the other way: larger branches, but with a short written plan at the top and commits split so a reviewer can read them in order. They frame it as empathy toward the reviewer, not as a size limit, and their reviewers prefer it. Elsewhere, teams lean on tooling that groups changes semantically, and others set an internal cap. Hard enforcement through pre-commit hooks is consistently the least popular option anywhere.

All of these work. The decomposition doesn't tell you which to pick. What it gives you is the price of the choice you've already made — and a price is the only thing that turns that argument from a culture war into a decision.

One more thing, coming for all of us

Raised by one of these teams, and it undermines our own metric, so we're passing it on.

As discovery moves into the repository — transcripts, immutable source-of-truth documents, regenerable solution files, task breakdowns written by agents — pull requests stop being purely code. They start carrying specification.

Which means your most advanced teams, the ones furthest ahead, will show up in a conventional delivery analysis as anomalies or as slow deliverers. You'll be penalising exactly the behaviour you want.

The fix is probably classifying by artifact type: markdown-dominant changes are discovery, code-and-test-dominant changes are implementation. And a better signal than volume is movement within the markdown — documents being split, merged, reorganised, pruned. That's craft. Mass generation of new files isn't.

We don't have that in our model yet. We're building it.

If you're measuring this at scale and getting different answers, we'd like to compare notes. The study behind our own 14-versus-6 figure is here.