Review Overhead When Agents Generate High PR Volume
Massive agent output overwhelms code review systems designed for human pace.
Coding agents now generate pull requests faster than any human review process was built to handle, and OpenAI Codex alone produced over 400,000 PRs in two months. This creates a structural mismatch between how code review was designed and how code now gets written, so the fixes that follow have to redesign the system itself.
How agent-generated PRs break code review
Code review, as a practice, assumed a rough balance between how fast people wrote code and how fast other people could read it. One engineer wrote a feature over a few days, and another engineer could reasonably expect to understand that feature in an hour or two. That balance held for decades because both sides of the equation moved at human speed. Coding agents removed one side of that equation and left the other unchanged, so the balance is gone.
The volume and complexity of the work moving through the queue changes directly as a result. None of this is reviewers getting more of the same work. They're getting something structurally harder to evaluate: bigger diffs, more surface area per change, and more defects buried somewhere in that surface area.
Process maturity does not fix this. A review checklist built for a five-file PR does not scale cleanly to a fifty-file PR just because the team that built it was disciplined.
AI coding tools produce far more individual output per engineer, yet organizational DORA metrics have shown no significant improvement, and delivery stability metrics have actually gotten worse at many organizations. More code entered the system than the system could validate and absorb. Output went up. Delivery did not. That gap shows the problem is structural, and the fix has to redesign the system itself.
Why AI-generated code resists standard review habits
There is a volume surge on top of code that has itself changed, in ways that make standard review habits less reliable. A reviewer who has read human code for years has built an instinct for where to look. That instinct breaks down against agent output, because the signals it was trained on are gone.
When a junior engineer writes flawed code, the flaws tend to announce themselves. Agent-generated code is idiomatic, giving off none of those tells. It is consistently styled. It is structurally tidy, often tidier than what a rushed human engineer would produce under deadline pressure. And it can still be wrong underneath all of that polish, with nothing on the surface pointing a reviewer toward the problem.
The failure modes that appear in agent code differ in kind, not just in frequency. None of these failures look like bugs on first glance. They look like finished work.
Catching them requires a different kind of reading. A reviewer has to reconstruct intent: what was this code actually supposed to do, not just whether it compiles and passes lint. That is a slower, more expensive cognitive task than spotting a typo or an off-by-one error, and it cannot be skipped just because the diff looks clean.
Agents compound this by never pausing on ambiguity the way a careful human engineer might. An agent fills the gap with its best guess and ships a fully working, fully tested implementation of that guess. The underspecified ticket does not produce a stalled task. It produces a polished PR built on the wrong assumption, and the ambiguity that should have been resolved before any code was written becomes something a reviewer has to untangle after the fact.
The numbers reflect this directly: AI-generated code carries materially more issues per PR than human-written code, with logic and correctness errors and security issues rising sharply. Adding more automated scanning on top of output that already looks clean treats a symptom. It does not touch the cause, and that gap sets up the most tempting wrong answer teams reach for next.
Why AI reviewers alone can't clear the backlog
The obvious move, when an agent-generated queue grows faster than human reviewers can clear it, is to point an AI reviewer at the queue and let it handle a share of the load. Early research on code review agents found they can reduce noise at the margins, but they do not address the structural issue, because the same assumptions baked into the original code tend to carry forward into the review of it.
A model reviewing code it generated, or code a peer model generated, inherits the same blind spots. Among closed PRs reviewed only by an AI agent, the study found reason to think low signal-to-noise ratios in that feedback contributed to PRs being abandoned.
Automated single-pass review is good at catching surface issues: obvious syntax problems, style violations, missing semicolons. It struggles with intent reconstruction, which is exactly the class of failure that matters most in agent-generated code. Noise is the most common complaint leveled against the category. A reviewer now has to evaluate the AI reviewer's output in addition to the original code, which adds a step to the process.
The deeper issue sits further upstream than any review step can reach. No amount of tooling at the review stage can compensate for a generation stage that started from a vague or underspecified prompt. Fixing review after the fact treats the output. The real lever is further back, in how the work gets handed to the agent to begin with.
Fixing what enters the queue: PR size limits and scoped agent task design
The single most effective lever on review overhead has nothing to do with review tooling. It's about constraining what agents are asked to produce in a single run. Smaller, better-scoped tasks produce smaller, safer PRs before any reviewer or review tool ever sees them.
PR size is the root variable in almost every measure of review cost. A PR that touches many files takes dramatically longer to review than one that touches a handful, and large PRs hide defects inside volume in a way small PRs cannot. This is not a surprising finding on its own, but it has a direct and underused implication for agent workflows: agents will produce large PRs whenever they are handed large tasks, because nothing in the task structure told them not to.
The fix sits at the ticket level, not the diff level. The constraint has to be built into how work is assigned, before an agent writes a single line.
Some categories of work are naturally suited to this kind of bounded, reviewable scope: adding tests, fixing lint errors, dependency updates, mechanical refactors, documentation syncs, and small, well-defined bug fixes. The safer path is incremental: start with tests and small fixes, move to low-risk refactors, then dependency updates, and only then take on more complex, multi-file work once the team has a track record with the easier categories.
Ticket quality turns out to be a throughput variable in its own right, not just a nice-to-have. Agents read ticket bodies as prompts, and a vague ticket produces a vague PR in the same way a vague instruction to a new hire produces work that misses the mark. A specific ticket, one with linked code, explicit acceptance criteria, and edge cases spelled out rather than implied, gives an agent something concrete to build against and gives a reviewer a known spec to check the output against afterward. The quality of the ticket shapes the quality of the review almost as much as the quality of the code.
Routing agent PRs by risk before they reach a human reviewer
Not every agent PR carries the same stakes, and treating them as if they did wastes the attention of senior engineers on changes that barely matter while leaving genuinely risky changes under-scrutinized. A documentation update and a change to an authentication flow do not deserve the same review posture, even if both arrived in the queue the same morning.
A triage layer placed before human review can sort PRs by risk signal. None of these signals require a human to read the diff first. They can be checked mechanically, before a reviewer opens anything.
Splitting review by concern rather than running one pass over everything catches more than a single reviewer or a single model checking for everything at once. One pass can focus on logic and correctness, a second on security, a third on standards and conventions, with each pass tuned to a specific class of failure. Context across the codebase matters here too: a review process that understands which downstream services consume a given utility, and which contracts depend on it, can catch risk that a tool looking at a single file in isolation simply cannot see.
The practical payoff of triage is that reviewers know, before they open a diff, what kind of work they're about to do. A sorted queue tells a reviewer whether the next PR calls for careful intent reconstruction or a five-minute sanity check, and that distinction changes how time and attention get allocated across a day far more than any individual review technique does.
Sandboxed environments as a review filter, not just a safety measure
An agent that can run its own output in an isolated environment before opening a PR catches an entire category of failures that would otherwise land on a senior reviewer's desk. The environment itself is doing review work, quietly, before the human queue even begins.
Standard containers are not built for this job, because they share a kernel with the host machine, which limits how much an agent can safely do inside one. The choice of isolation technology determines what an agent can safely be allowed to do: install packages, run background services, drive a browser for integration testing, without risking state leaking across runs or the host itself being compromised.
Inside a properly isolated environment, an agent can install dependencies, run full test suites, lint its own code, drive a browser to check an integration flow, and verify its own output before a PR ever opens. Any failure caught at this stage stops there, before the human review queue. That is the entire point: it is cheaper, by orders of magnitude, to catch a failing test inside a sandbox than to catch the same failure in a code review that costs a senior engineer twenty minutes of focused attention.
An ephemeral lifecycle matters as much as the isolation technology itself. Environments created on demand and destroyed after use prevent state from leaking between agent runs, so each run starts clean and earlier drift can't quietly corrupt the output of a later one. Lovable uses Modal Sandboxes as preview environments for the apps and websites its platform generates.
Enterprise deployment of this pattern needs more than the sandbox alone. The sandbox is the foundation this is built on, not the whole structure.
Integrating agent PRs into existing review workflows without adding new tools
The teams absorbing high agent PR volume most successfully routed agent output through the communication and tracking tools their engineers were already using every day.
Triggering an agent from wherever work already lives, a Slack message, a Linear issue, a GitHub label, means the handoff into agent mode asks nothing extra of the engineer. The agent becomes one more participant in an existing conversation rather than a parallel process running somewhere else.
Automated PR-to-issue loops close a different gap: queue invisibility. An agent that polls for PRs that have stalled, opens a Linear issue when a review has sat untouched too long, and posts a daily Slack digest summarizing the state of the queue acts as a queue manager on its own. No human has to remember to check whether something has been sitting for three days.
Harness agnosticism matters once a team is running this at any real scale. The integration layer connecting ticket systems, chat tools, and the PR queue should stay agent-neutral, so a team can delegate work to Claude Code, Codex, or Opencode depending on which is best suited to a given task, without having to rebuild the surrounding workflow every time the choice of agent changes.
Measuring review health as a first-class engineering metric
Teams running agents at scale need a different set of numbers than the ones that mattered before, because the old metrics now actively mislead. Raw volume says nothing about whether what got merged was any good.
A more honest picture starts with where PRs are actually losing time in the pipeline, broken down by whether they're stuck waiting on review, stuck in testing, or stuck in deployment, since each of those bottlenecks calls for a different fix. Review load distribution matters just as much: a queue where a handful of senior engineers are absorbing most of the backlog while others sit with spare capacity is a distribution problem, not a volume problem, and no amount of new tooling fixes it on its own. And the zero-review merge rate deserves close attention on its own: a rising number there is far more likely to mean the queue has outpaced the team's process than that code quality has quietly gotten better.
None of these numbers are useful without attribution that goes deeper than simply labeling a PR as agent-generated. Knowing which harness produced it, which model was behind it, what triggered the run, and which environment it executed in tells a team exactly where to invest further and where to tighten constraints, turning a vague sense that "the agents are producing more bugs" into a specific, actionable finding about one harness, one model, or one task category that needs a narrower scope or a closer review pass.