Everyone measuring AI-assisted development is reporting the same shape of result: output is up, and the cost of checking that output is up much more. I want to walk through the numbers, because the gap between the two is larger than most teams have adjusted for, and then say what it looks like from inside a small team where I do most of the reviewing myself.
What the telemetry says
Faros AI published an engineering report built on two years of telemetry from 22,000 developers across more than 4,000 teams. Not a survey about how AI feels, but workflow data before and after AI adoption inside the same organisations.
The delivery side improved:
- task throughput per developer up 33.7%
- epics completed up 66.2%
- pull request merge rate up 16.2%
The review side moved differently:
- median time a pull request sits in review up 441.5%
- average review time up 199.6%
- median time to first review up 156.6%
- daily pull request contexts per developer up 67.4%
Two numbers in the same report describe what happens when that pressure has nowhere to go:
- pull requests merged without any review up 31.3%
- incidents-to-PR ratio up 242.7%
So teams write more, and the queue in front of the reviewer grows faster than the queue behind the author. Some of that queue gets resolved by not reviewing at all, and the incident numbers follow.
What developers say about it
Sonar's State of Code Developer Survey, published in January 2026 with more than 1,100 developers, adds the human half:
- 96% do not fully trust that AI-generated code is functionally correct
- only 48% always check AI-assisted code before committing
- 38% say reviewing AI-generated code takes more effort than reviewing code written by a colleague
- AI accounts for 42% of committed code
Read the first two together and you get the shape of the problem. Almost nobody trusts the output, and barely half of them verify it. The trust gap does not turn into review work automatically. It turns into review work for the people who have the discipline or the responsibility, and into risk for everybody else.
That 38% is the number I recognise most.
Why checking is more expensive than writing
When you write code yourself, the mental model builds as you go. By the time the last line is in place you already hold the reasons behind every decision, including the ones you rejected. Review is not that. Review is reconstructing a model backwards from a finished artefact, without the discarded branches, without the moment where the author decided this approach was worth it.
That is expensive with a colleague's code, and it is more expensive with a model's code, because a model produces plausible work uniformly. A colleague signals uncertainty. Their commit message hedges, they leave a comment, they ping you about the part they are unsure of. Generated code arrives with the same confident surface everywhere, so the reviewer has no gradient to follow and has to give every section the same level of attention.
Add the context switching. A 67.4% increase in daily pull request contexts means the interruptions do not just multiply, they arrive on someone else's schedule. Work that runs on its own still comes back to you, and it comes back at a moment you did not choose. Each return costs the reload of a context you had already put down.
What this looks like on a small team
I build a product mostly by myself, with agents doing a growing share of the mechanical work. Automation ate the typing. It did not touch the checking, and it multiplied the number of things waiting to be checked.
I still cannot take a result from a model and send it to production without looking at it. Not once has that felt safe. So a layer of review always stays, and that layer is where the day actually goes. I have used AI coding tools for a long time, but the load only became obvious once individual completions turned into a set of automations running in parallel. The bottleneck stopped being how fast I write and became how fast I can rebuild context for work I did not do.
I do not have a clean set of rules that solves this. The things that visibly help me are unglamorous:
- smaller units of generated work, because review cost grows faster than diff size
- fewer parallel threads, even at the cost of throughput, because each extra thread taxes every other one on return
- tests written before generation, so a chunk of verification runs without me holding the whole model in my head
- treating "I do not understand why this works" as a blocking result, not a stylistic complaint
None of that closes the gap. It moves it a little.
The part worth arguing about
The industry conversation is still mostly about generation quality, on the assumption that better models shrink the review burden. The telemetry suggests review load is not a bug in current model quality but a structural property of delegating work you remain accountable for. Even at high accuracy, someone has to hold responsibility, and holding responsibility means rebuilding context.
That is why the productivity number and the review number in the Faros report should be read as one result and not two. Throughput up a third, review time up more than four times over. If your planning captured the first number and not the second, your team is absorbing the difference somewhere: in senior engineers' evenings, in merges nobody looked at, or in the incident count.
Where does your review time actually go, and what have you changed to make it survivable?
Sources: Faros AI, "The AI Engineering Report 2026: The Acceleration Whiplash" (telemetry from 22,000 developers across 4,000+ teams). Sonar, "State of Code Developer Survey 2026" (1,100+ developers, published January 8, 2026).
Top comments (0)