The invisible ceiling of code agents: a single developer reviews 8 out of 10 PRs

In other words: the volume of code an agent produces doesn't predict how many people review it. It predicts, rather, how much time one person spends staring at a diff.

It's worth clarifying the study's scope: it measures what happens within the analyzed window—who reviews, who merges, how often—not what happens after. Reverts, bugs that appear weeks later, or how well that code ages in production are outside the dataset. That doesn't invalidate the finding; if anything, it suggests the real problem—sustained quality of agentic code under single-person review—is probably bigger than these numbers already show.

The pattern that doesn't change with scale

The most revealing part isn't the overall average, but what happens when volume goes up. Raida re-examined small teams that exceeded 30 agentic PRs in the study window—the ones that put the most pressure on the system—and found thatthe majority still operated under the same single-reviewer setup.

"Even among the most active small repositories, the majority of agentic PRs continued to follow a single-reviewer workflow. This suggests that increased agentic activity did not necessarily lead to more distributed review practices", Raida explained to Help Net Security.

Small teams, disproportionate load

One to five-person teams not only use more agents: they use them disproportionately compared to medium and large teams. It makes sense—they have the least organizational friction adopting a new tool—but they also have the least margin to absorb a review queue that grows without the team growing.

Feature vs. fix

The study also found a usage difference: in single-reviewer workflows, the most common PR type wasnew features. In workflows with multiple reviewers or committers, fix PRs dominated.Fix PRs. Solo maintainers point their agents at building. Teams with more than one person use them more for fixing.

Why review is the real ceiling

Here's the point almost nobody's discussing out loud: the conversation about code agents has spent two years focused on how much code they can generate. That problem is basically solved. The problem that remains—and that this study shows with numbers—is thathuman review capacity doesn't scale at the same rate as generation capacity.

A developer has a finite number of hours to read diffs, run tests, and decide if something deserves to merge or not. More agents means more PRs, not more review hours available. The 25 projects in the study that generated agentic PRs at the pace of a professional developer (using a Worklytics benchmark as reference) are the exception, not the norm. The rest simply haven't gotten there yet—or have hit the same ceiling without realizing it.

This connects to something you already see in almost every coding agent on the market: adoption of the MCP protocol (Model Context Protocol) lets them connect to more data sources, more APIs, and more tools, which in theory multiplies what an agent can automate end-to-end. But each new integration also multiplies the surface a human has to understand to judge whether the result is correct. More context for the agent isn't free for whoever reviews it.

What this means for agencies and developers

For an agency like ours, or for any development team putting Claude Code, Copilot, or Codex into their daily flow, the message is direct:

• Don't optimize generation alone. If your team measures success in "how many PRs does the agent open per week", you're measuring half the problem. The other half is how many people can review without burning out.
• Design the review process before you scale agent use. Defining who reviews what type of PR (features vs. fixes), with what checklist and what SLA, prevents a single dev from becoming your whole team's silent bottleneck.
• Watch the small teams. If your agency operates with 3-5 person squads per client—as usually happens in consulting—this is exactly the profile the study identifies as highest-use and highest-risk for review overload.
• Similar merge rate between single reviewer and group isn't validation that "we don't need more people". It's a signal we haven't stressed the system hard enough yet to see where it breaks.

The underlying lesson is that a team's productivity with AI agents isn't measured in lines of code generated, but by how fast that code becomes something merged, tested, and in production with confidence. That's still, today, a human problem.

At Geek Vibes we're already adjusting our squads' review flows before we turn up the dial on code agents, precisely to avoid hitting that same ceiling without seeing it coming. If your team is at that point—generating more code than you can review with quality—let's talk:comercial@geekvibes.agency.