AI's Code Review Bill Lands on Senior Engineers

After Copilot arrived, core developers reviewed 6.5 percent more code and shipped 19 percent less of their own. Where that cost lands.

Your team merged more pull requests last quarter, and your best engineer shipped less of their own work. Those two numbers are connected. AI coding tools do not remove review work, they relocate it, and the destination is the small group of people you can least afford to occupy. In open-source projects studied after GitHub Copilot arrived, experienced core developers reviewed 6.5 percent more code while their own original output fell 19 percent. The throughput you gained was partly funded by your most expensive engineers writing less.

Most adoption analyses stop at whether output went up. The more useful question for anyone holding a budget is which part of the organization absorbed the verification work. That cost concentrates. No dashboard counting merged pull requests will show it, because lowering the cost of producing a change does nothing to lower the cost of being responsible for it. Someone still holds that, and it is usually your most senior person.

Senior review load rose while senior output fell

One study produced both numbers, and its design decides how much weight they carry. Researchers split open-source contributors by experience level and compared activity before and after Copilot appeared. Overall productivity did rise, but the gain concentrated among less experienced peripheral contributors, and code written after adoption needed more rework to satisfy repository standards. Core developers absorbed that rework. They reviewed 6.5 percent more code and saw their own productivity drop 19 percent. The authors conclude that AI productivity gains may mask a growing maintenance burden falling on a shrinking pool of experts, and they locate the drag on senior output in that burden rather than in review volume alone. Nothing here says the tool is bad. The accounting is incomplete.

Sources: AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden (arXiv)

The asymmetry is what makes this expensive. Review capacity does not scale with contribution volume, because the people qualified to review the hard changes are the same people who were writing the hard changes. When submission cost falls and review cost does not, the code review bottleneck forms at the narrowest point in your organization.

Not all review got harder in the same way. Reviewing a change written by a colleague carries context you can rely on: you know what they were working on, roughly how they think, and which parts they are likely to have gotten right. AI-generated code arrives without that. It is uniformly confident. The section the agent understood least reads exactly like the section it understood best, and nothing in the diff tells you which is which. So the reviewer does a job nobody budgeted for, working out which parts of the change were ever thought about before judging whether they are right.

How large is the gain you are redistributing?

For most organizations the gain is a single-digit to low double-digit percentage, not a multiple. DX tracked more than 400 companies from November 2024 to February 2026. AI tool usage rose 65 percent on average. Median pull request throughput rose 7.76 percent, with a mean of 13.1 percent. Atlassian's State of Developer Experience survey of 3,500 developers and managers across six countries puts coding at roughly 16 percent of how engineers spend their time, which caps how much any coding accelerant can move the total. A large adoption number and a modest throughput number are not in conflict. They are what you should expect when a tool speeds up a sixth of the work and the other five sixths stay where they were.

Sources: LeadDev: AI productivity gains are closer to 10 percent than 10x, Atlassian: State of Developer Experience report

Enterprise numbers can run higher. Microsoft researchers studying tens of thousands of engineers during an early-2026 rollout of Claude Code and Copilot CLI found that engineers who adopted the agents merged roughly 24 percent more pull requests than they otherwise would have, and the lift held across a four-month window. The authors flag the limit themselves: a merged pull request is not the same as the value it delivers. That figure is also not comparable with the 7.76 percent above. One is an organization-level median across more than 400 companies, the other a per-adopter difference inside a single company, so the median is the closer analogue for most organizations.

Sources: Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI (arXiv)

Why AI code review costs behave like a commons problem

The cost does not vanish, it changes hands. The person who submits captures the speed gain. Reviewers and maintainers absorb the verification, and nobody asked them whether they wanted the trade. A qualitative analysis of 1,154 Reddit and Hacker News posts, published as An Endless Stream of AI Slop, identified three recurring themes: review friction, quality degradation, and the forces and consequences driving both. The authors caution that this kind of analysis captures the range of developer perceptions rather than their prevalence. The first two themes describe the same reviewer-side mechanics from opposite sides. Review friction is volume arriving faster than anyone can apply judgment to it. Quality degradation is what gets through when it cannot. Their conclusion names the structure outright: a tragedy of the commons, in which individual productivity gains externalize costs onto reviewers, maintainers, and the broader community. Every individual decision is locally rational. The aggregate is a review queue nobody agreed to.

Sources: An Endless Stream of AI Slop: How Developers Discuss the Burden of AI-Assisted Software Development (arXiv)

Godot now bars substantially AI-generated code

The Godot Foundation requires code to be human-authored. It bars autonomous agents and substantially AI-generated code while still allowing AI for menial help such as completion, regex, and find and replace, with disclosure. Its reasoning is this article's arithmetic stated plainly: the effort required to make a pull request has gone down, the number of pull requests has risen as a result, and the work to review them and the number of people available to review have stayed the same. The policy is also blunter than most vendors will ever be about what AI did and did not cause. "This reviewer shortage was already a problem, but it was one that we successfully ignored," it says. Then it makes the accountability argument: AI cannot take responsibility, and the Foundation does not trust heavy AI users to understand their own code well enough to fix it. For a volunteer-maintained project with a fixed reviewer pool, that is a defensible read of the same numbers.

Sources: Godot Foundation: Changes to our Contribution Policies

The mentoring cost that shows up two quarters later

The second cost is mentoring capacity, and the evidence for it is thinner than the numbers above. Review is how less experienced engineers learn what good looks like in a specific codebase. Shift senior capacity from writing to reviewing and the volume of review climbs while the depth per review drops. Load cuts the teaching out of a review first. A queue cleared with terse approvals looks identical in the metrics to a queue cleared with teaching.

The near-term version of this is reviewer burnout, which at least announces itself. Compound it further and you get a team that ships more this year and has fewer people capable of reviewing the hard changes next year. That is not an argument the data settles, and anyone claiming precision about it is guessing. It is a reason to treat senior review hours as a scarce resource with a strategic use rather than as a buffer that absorbs whatever volume arrives.

Should you restrict AI coding tools?

Restricting AI coding tools is not what the evidence supports. The 2025 DORA report on the state of AI-assisted software development, drawn from nearly 5,000 technology professionals, reversed its own earlier finding and reported a positive relationship between AI adoption and both delivery throughput and product performance. AI adoption continued to show a negative relationship with delivery stability. Read together, that is not an argument against adoption. The gain shows up in throughput. The cost shows up in stability. A gate exists for exactly that split. The stability half also lands back on the same people. Whoever understands the system best ends up diagnosing the incidents, and that is the same short list of engineers already absorbing the extra review, so a stability regression and a review backlog draw down one budget, not two.

Sources: Google Cloud: announcing the 2025 DORA report

Now the uncomfortable half, which applies to every vendor in this space including us. If your organization sits near that 7.76 percent median rather than anywhere close to the per-adopter figure from a single large company, then reassigning two staff engineers to full-time verification is a bad trade, and no amount of tooling changes that arithmetic. Measure your actual lift before you spend it. A team capturing single-digit throughput gains while burning senior capacity on review has bought a cost, not a benefit, and the correct response may be to slow adoption until the gates are cheap enough to be worth it.

What a leader can actually change

Every change below reduces the same quantity: how much unfiltered volume reaches a staff or principal engineer. They are ordered roughly by how cheap they are to put in place, and none of them require a new tool.

• Cap pull request size. A size cap is the cheapest gate you can add, and it is what stops a large agent-authored change from arriving as one unreviewable unit.
• Require a written spec before implementation, so review is against stated intent rather than a cold read of consequences.
• Move mechanical checks off humans entirely. Anything a linter, type checker, or CI gate can decide should never reach a staff engineer.
• Define what the first review pass is allowed to decide. A gate can catch missing tests, unstated assumptions, and changes outside the described scope before a human ever opens the diff, and writing that list down is what keeps the human pass about judgment.
• Measure senior original output, not just team throughput. It is the number that falls silently when review load rises.
• Decide explicitly who absorbs verification. Left undecided, it defaults to whoever cares most, which is your most senior engineer.
• Require the author to state what they verified themselves. An unreviewed agent diff forwarded to a staff engineer is one engineer handing another engineer the bill.

Put the first review pass before the human one

The structural fix is to place a competent reviewer before the human one, so the volume that does not require judgment never reaches the person whose judgment you are paying for. That is what TLM Forge is built to do: a spec audit that fixes intent before code exists, and a review pass the change has to clear before the commit lands. It does not remove human review, and it should not. It changes what arrives at human review, so a staff engineer is approving a change that has already cleared a check rather than performing the check personally.

AI adoption moved a cost rather than removing one. Teams that locate the new cost and staff it deliberately keep the throughput gain. Teams that do not keep reporting higher merge counts while their most experienced engineers quietly stop building anything.

If you want a single diagnostic to run this quarter, compare two numbers for your three most senior engineers: hours spent reviewing, and changes authored. If the first has risen and the second has fallen, you have found who is financing your throughput gain. That is not automatically a bad trade, because senior review time can be worth more than senior authoring time, but it should be a decision somebody made rather than a drift nobody noticed. A useful threshold is whether review time now exceeds authoring time for anyone on that list, because that is the point at which the job changed without anyone renaming it.