Why does code review become a bottleneck when AI agents write more code?

In a study of 655 firms, pull request (PR) openings grew faster than merges in the year after coding-agent adoption. A Harvard working paper estimated that openings per worker-month rose 35.7% and merges rose 26.0%. Time from submission to merge rose 56.1%.

When PRs pile up, are they waiting for someone to pick them up or getting stuck after the first response? Who has enough context to review them, and does AI review take any of the load? Each answer points to a signal you can check in your own repositories, from time to first response to review load by code area, and to changes you can make before a PR reaches review.

Where the extra pull requests pile up

Openings grew faster than merges, so the queue grew. The estimated merge delay was about two extra days on a 3.6-day baseline. Among PRs with comments, the wait for a first human comment from someone other than the author and the time from that comment to merge each rose by about 60%. The estimated increases in completed work, measured as Jira issues and epics resolved per worker-month, were smaller and statistically imprecise.

When does adding reviewers help?

Someone who knows the service can spot a change that passes its tests but breaks a caller's assumptions. In the Harvard study, 82.8% of reviews took place in a codebase where the reviewer had previously committed code or opened a PR. Senior engineers did 75.7% of the reviews on PRs written by other senior engineers and 32.8% of those on PRs written by junior engineers.

After coding-agent adoption, estimated time to merge rose 69.7% at firms in the top third by the average number of repositories receiving PRs each month, compared with 25.4% in the bottom third. The researchers used baseline repository count as a proxy for codebase complexity. They suggest that review may be harder to redistribute across more complex codebases.

Consider a billing change that only two engineers know well. An agent opens three related PRs in a day, but each still competes for those engineers' attention. General reviewers can check tests and local code structure, but the billing decisions still wait on the same two people.

Adding reviewers helps when they take work off the owners' plate. Ask the billing owners to flag which decisions need their input, such as a change to a pricing rule or a data migration. Let other reviewers handle test coverage and local code structure where those checks can stand on their own. If the same owners are still holding up approvals, reserve review time on their schedules and pair another engineer with them. Record why they accept or reject changes so the second engineer can make those calls on future PRs.

An engineering lead in an r/ExperiencedDevs discussion described a similar split by risk. When a pilot produced more agent-generated work than the team could comfortably review, they tried lighter checks in low-risk areas and asked how to handle the rest. A reply in the thread argued that review also transfers knowledge and makes the team responsible for maintaining the code.

On GitHub, a .github/CODEOWNERS file on the base branch can route ready PRs to the people responsible for changed files. A separate branch rule or ruleset can require an owner's approval. When multiple owners are listed for the same file, one owner's approval satisfies that requirement. GitHub Free supports code owners in public repositories; private repositories require Pro, Team or Enterprise. Routing identifies the right reviewers, so check whether they have time to take on the requests.

Can AI review take some of the load?

By July 2026, 79.1% of firms in the Harvard study had used an AI review tool, and 10.8% of PRs received at least one AI comment. Those figures measure use. Whether the tools shortened review remains an open question.

In a small 2025 study at WirelessCar, ten participants tried prototype review assistants built with o4-mini. Participants generally preferred the AI-led mode for large or unfamiliar PRs and raised concerns about false positives. The study measured participant experience, not the tools' effect on defects or review time.

If you trial an AI reviewer, track which comments lead to meaningful changes and how long people spend checking its suggestions. Have a human reviewer sample changes for issues the tool missed.

Find your team's constraint

Start with the path a change takes, from a PR marked ready for review through merge and deployment. A single cycle-time number can hide several different problems.

Use these measures to understand the workflow, and agree on definitions first. A first comment might be a request for more information, while an approval might be followed by a long wait for a deployment window. Compare similar kinds of work over time, and inspect a sample of changes behind the numbers.

Engineering analytics vendor LinearB reports that, at the 75th percentile in its dataset, agentic PRs waited 17.6 hours for pickup, compared with 3.4 hours for unassisted PRs. The groups can differ in priority, size and ownership. LinearB itself notes that agents may work on low-priority backlog items with no expectation of immediate review.

What to change before a PR reaches review

Keep changes small enough to understand. Google's engineering guidance recommends self-contained changes that address one thing and include related tests. A reviewer can assess the behavior without reconstructing an entire feature. Splitting a change into many dependent PRs can create its own coordination cost, so agree on useful boundaries before asking an agent to produce them.

Give the reviewer the task and the evidence. A PR should say what changed, why it was needed, which behavior was checked and what remains untested. Include a link to the requirement or decision where one exists. A generated summary can help navigate the diff, but the author still needs to verify it against the code and test results. Our earlier look at source control for AI agents examines tools that preserve more of the context behind a change.

Protect attention for the riskiest decisions. A documentation correction and a change to payment authorization need different scrutiny. Define risk categories with the people who own the systems, then agree which automated checks and human approvals each category needs. Test any lighter path on a limited set of changes and watch for rework and incidents. Do not remove independent review of a sensitive path solely because an agent reports that its tests pass.

Where to start

As we argued in our article on the two-week sprint, faster implementation makes verification more important. Start with one repository or team, map the intervals from review request to deployment, and inspect the oldest waiting changes. Track how long changes wait for their first response, how many review rounds they need and what happens after deployment. Use those observations to decide whether the next change should address reviewer availability, the handoff or another stage.

About the study

Fiona Chen and James Stratton's November 9 working paper uses Jellyfish records covering 720,542 workers at 655 firms from January 2021 to August 2026, including GitHub activity and Jira work items. The authors compare firm-level outcomes across companies that adopted agents at different times. Their approach assumes those firms would have followed similar trends without adoption. The estimates use a pre-agent baseline when firms had typically already adopted coding assistants. The paper has not been peer reviewed.

The authors partnered with Jellyfish. They say the company reviewed the manuscript for proprietary disclosures and did not review its scientific content.