Coding Agents Moved the Bottleneck From Writing to Reviewing PRs

Coding agents multiplied the pull requests every team opens, but the number of people reviewing them has, for quite some time, been flat.

Open the pull request queue at almost any team that adopted coding agents this year, and the backlog tells a story the velocity dashboard never shows. Requests that once arrived at a pace a reviewer could absorb now stack up faster than anyone can work through them, and each one carries more code than the last.

Nothing about that queue looks like a crisis, which is most of the reason it goes unaddressed for so long. The work is getting done, the features are shipping, and the engineers responsible for reading all of it are making a choice every day about how carefully they can afford to look. And so the constraint that coding agents removed from the generation side of software development did not disappear.

It moved to the review side, and it deepened.

Velocity Metrics Hide What Review Is Costing

The instruments most organizations use to track AI adoption were chosen before coding agents entered the workflow. So they still point almost entirely at the generation side, telling leaders how much is being produced without saying anything about the quality of that output or the strain on the people reviewing it. I wrote earlier about the validation debt that dashboards are not showing (https://devops.com/validation-debt-that-your-dashboards-are-not-showing/), and an overloaded review queue is usually one of the first places where that debt starts to build.

Mayank Bhola, co-founder and head of products at TestMu AI, sees this as a problem that sits upstream of the technical architecture. It decides whether engineering leaders respond to the review bottleneck before something goes wrong or only after it does. “Engineering leaders are looking at throughput metrics and seeing productivity gains, but they are not seeing the compounding quality debt that accumulates when review capacity does not scale with generation capacity,” Bhola explains. He adds that the first sign of that debt is usually how long pull requests sit untouched and how thinly they get read once someone finally opens them.

It is a pattern he sees repeatedly in organizations that moved quickly on AI. “At TestMu AI, we see this pattern consistently across enterprise teams that have adopted coding agents aggressively,” he notes. “The PR volume increases dramatically. The review queue grows faster than the team can process it.” Because AI-generated code looks clean and passes basic tests, the most important problems slip through because reviewers no longer have time to look closely. Those include architectural drift or a security assumption that only breaks at scale.

Throughput gets measured because it is easy to collect and easy to credit to AI adoption. Quality debt is harder to define and easy to dismiss until the day it can no longer be ignored. That is why Bhola recommends that leaders instrument the review side with the same seriousness they give velocity.

A sensible starting point is tracking how long pull requests wait for a first review alongside how much code each reviewer approves in a day. Without that, most organizations keep measuring what is easy to measure until an incident or a failed audit makes the quality numbers urgent.

Ten Times the Code, the Same Reviewers

Seeing the size of the problem those dashboards miss comes down to plain arithmetic. Once the numbers are laid out side by side, it becomes clear why adding reviewers has done so little for the teams that tried it.

Itamar Friedman, CEO and co-founder of Qodo, treats the review bottleneck as an operational problem that engineering leaders are already living with, often well before they have a name for it. Until recently, the typical developer opened two pull requests a week of roughly a hundred lines each, which a reviewer could read with real attention without slowing the team down. Coding agents changed both sides of that equation at once. The same developer may now open two to five pull requests a day with up to a thousand generated lines in each. So the code arriving for review has grown by an order of magnitude, while the number of people reading it has stayed where it was.

Friedman puts the stakes in terms that land with any engineering leader. “You are a technical leader and you are seeing your team leaning on AI and spitting out a lot of features,” he argues, “but then you are at the risk of having code rot, having quality rot. And the first day you have a CrowdStrike moment in your software, who do you blame? Do you blame the AI or do you blame yourself for not making it clear that quality matters?” His question points to an uncomfortable dynamic. Visible feature velocity keeps the pressure on to move fast, while the quality debt building underneath stays invisible until it surfaces as an incident. A leader who lets generation scale without scaling review has made a decision, even if that decision was to do nothing.

The density of what arrives turns this from a capacity problem into a quality problem. Even if AI-generated code carried no more issues per line than human-written code, ten times the code would still put ten times the issues in front of the same reviewers, and many of them look like clean code until someone with enough context reads them closely. One practical way to ease that pressure is to cap how much generated code a single pull request can carry. A reviewer reads a hundred-line diff with far more care than a thousand-line one, and the cap brings review back to the size of work it was designed for.

Smarter Review Beats Slower Generation

Hiring more reviewers to absorb the overflow is the response that fails most predictably. Generation compounds while headcount grows one hire at a time, so any lasting answer has to scale with generation and not try to hold it back. That answer depends on building review agents on different terms from coding agents. A coding agent is rewarded for producing code that compiles and meets its requirements. A review agent has to be rewarded for catching what the coding agent missed without raising false alarms. Those two goals pull in different enough directions that one model rarely does both jobs well. I wrote earlier about AI testing frameworks that pass tests they should be failing, and a review agent built on the same model as the coding agent inherits the same blind spots for exactly the same reason.

Bhola sees the product consequence clearly. “The solution is not slower generation. It is smarter review, which means AI that is specifically designed to catch what human reviewers miss under pressure rather than AI that generates more of what already needs reviewing.” TestMu AI applies the same principle in Kane CLI, its testing agent. Everything an agent proposes starts as derived and only becomes trusted after a person reviews it, so the agent that generated a test is never the one that approves it.

The bottleneck has moved to review. Teams that treat it as an architecture problem will build review capacity that grows with generation, while teams that treat it as a hiring problem will keep adding reviewers to a queue that outpaces them. The most practical first step is to put review wait time and review depth on the same dashboard as the velocity numbers leadership already reads. That way, the cost of the trade-off becomes visible well before an incident forces the conversation.