lorenzopasquali.dev

79% of engineering leaders say code ships faster but releases don't. I checked the math

· 6 min read · also in Portuguese

On October 7th, InfoQ covered a survey whose most interesting number is not the one that will circulate. What will circulate is "42% of the week debugging". What deserves attention is this: 79% of engineering leaders say that even though they produce code much faster with AI, release cycles are no faster than before.

Think about what that says. For decades, writing code was the stage we thought limited delivery. If AI makes that stage cheap and the release stays where it was, then code was never what held the release back. It was just at the front of the queue, hiding everything else.

The report is from Undo, published in early October, with 300 engineering leaders. I read the whole PDF. Before getting to what it suggests, a short caveat about how much to trust the numbers.

The numbers are orders of magnitude

The report's hours (9.8 writing code, 9.7 debugging during development, 7.2 debugging production issues, and 13.3 on other tasks) add up to exactly 40.0. And the report's page says the percentages assume "an average 40-hour working week". So the "42%" is hours divided by 40: an estimate over an assumed denominator, not a measurement.

The sample is 300 managers and no individual developers, 93% of them work with C/C++, and Undo sells execution recording for agents, which is exactly the solution the report recommends at the end.

So I would treat the numbers as orders of magnitude. What interests me is the pattern behind them, because it shows up independently elsewhere. Faros AI analyzed telemetry from more than 10,000 developers (and also sells engineering analytics, so the same asterisk applies) and found that teams with high AI adoption complete 21% more tasks and merge 98% more pull requests, while review time rises 91%. According to analyses that cite the report, there was no significant correlation with improvement at the company level.

More code gets out, and the release doesn't keep up. Two different instruments, the same shape. Now to the why.

Writing code was a quarter of the week

Using the report's own table, writing code is 9.8 of 40 hours: about 25%.

By Amdahl's law, if you speed up a stage that takes 25% of the work, the total gain has a ceiling. Doubling the speed of writing code gives something like 1.14x. Making writing infinitely fast would give 1.3x at most. These are calculations on estimates, so orders of magnitude again, but the message is clear: even in the best case, speeding up generation alone barely moves the total.

And that is still person-effort. A release is not effort, it is a queue.

A release is a queue, not effort

A human reviewer has fixed capacity. If the number of PRs reaching them doubles, the wait doesn't double: it explodes, because in simple queueing theory the wait grows as ρ/(1−ρ), where ρ is how busy the reviewer already is.

Reviewer utilization Relative wait
50% 1x
80% 4x
90% 9x
95% 19x

It is a model, not a measurement, but it explains something that looks odd in Faros's numbers: review time rising 91% does not require the load to have changed absurdly. Close to saturation, a little extra load becomes a lot of waiting. And that is exactly where a team with fixed reviewers and PRs that have doubled finds itself.

Where the queue is: three suspects

The data points to three places, and whoever points has a bit of interest in each.

Review. That is Faros's reading, and GitLab says, in its 2026 AI accountability report, that 85% of respondents agree AI moved the bottleneck to review. In Undo's survey, 50% say they spend excessive time reviewing agent output compared with how long it took to generate, and 46% find it hard to review the volume arriving. The mechanism is simple: generating became cheap, understanding did not. And 35% of generated code, according to the report, reaches production without having been fully understood.

Batching and deploy after approval. Steve Fenton, of Octopus Deploy, argued in July at The New Stack that review is not the bottleneck: the bottleneck is the queue after it. More than 90% of the teams he surveyed ship in batches, and half have 2 to 10 changes per batch. The test he proposes is good: count how many changes have been approved but are not yet in production. If it's more than one, the bottleneck is after review. His data is not yet published, and Octopus sells deployment tooling.

Defects and rework. At Undo, 91% of leaders had test escapes or serious defects in production at least once in six months, 81% had an incident or outage, and 55% say agents introduce incorrect code often enough to delay delivery. DORA 2025 sums up the same picture: AI improves throughput, but often at the cost of stability if the foundation isn't solid.

Notice that each source tends to point at its own backyard: Undo at debugging, Lightrun at runtime visibility, Octopus at batched deploys. Probably all three are partly right, and the answer depends on where your team's queue is.

A slower release may be the rational response

This is the part that interested me most. What ties the three suspects together is batch size. More code per unit of time means more changes per release and larger PRs. More changes per release means more risk per release. And an organization's response to more risk is to add a gate.

According to VentureBeat, that is what Amazon did after two outages in March that the report attributes to AI-assisted changes pushed to production without proper approval: a 90-day safety reset across 335 critical systems and a requirement that AI-assisted changes be approved by senior engineers before deploy.

So a release that didn't speed up is not necessarily a process failure. It may be the organization recognizing, correctly, that it cannot verify at the speed code arrives. The hard thing to speed up is accountability: nobody can outsource to the model the "I approve this and answer for it". And that capacity to verify is limited by people and by budget. In the part of the report that got the least coverage, 63% of leaders say cost is prohibitive for authorizing top-tier models for exactly the work of understanding and debugging code, and 82% fear agent prices will skyrocket as the labs prepare to go public. The remedy the report proposes, more AI in verification, runs into the same cost problem.

What I would measure

If the question is where your team is losing time, I would not measure hours writing or debugging. I would measure where the change waits:

Verdict

Code got cheap. Understanding did not. The bottleneck left the keyboard and moved to the head of whoever approves, and to the queue of everything that comes after. Whoever optimizes only generation will see PR volume go up and the release stand still, and will be tempted to conclude AI doesn't work, when in fact it worked on the stage that was no longer the limiting one.

The report's number is fragile. The pattern it describes is not.

Sources

← All posts