# What is the code review bottleneck? The code review bottleneck is the queue that forms when agents open pull requests faster than people can review them, so reviews slow down or get skimmed. Last updated September 29, 2026, 8 min read ## Learning objectives After reading this article you will be able to: - Define the code review bottleneck - Explain how agent output strains reviewers - Identify checks that find failures before review ## Related content - [What is code review?](https://specstory.com/learning/code-review/code-review) - [Why does pull request size matter?](https://specstory.com/learning/code-review/pull-request-size) - [How to review a pull request written by a coding agent](https://specstory.com/learning/code-review/reviewing-agent-pull-requests) - [What is AI code review?](https://specstory.com/learning/code-review/ai-code-review) ## What is the code review bottleneck? The code review bottleneck is the backlog of [pull requests](https://specstory.com/learning/glossary#pull-request) that builds up when changes arrive faster than reviewers can read them. [Coding agents](https://specstory.com/learning/ai-coding/coding-agent) can cause it, and changes then wait longer to merge or get approved after a quick look. It is also called the review bottleneck, and the strain on reviewers is often called review fatigue. [Code review](https://specstory.com/learning/code-review/code-review) needs a person's time for each change, and reviewers' hours do not grow when a coding agent writes more code. [Google said](https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/) in April 2026 that 75% of its new code is AI-generated and then approved by engineers. Each of those approvals takes time from an engineer. A long queue also changes what an approval means. When reviewers skim to keep up, the result is a [rubber-stamp review](https://specstory.com/learning/glossary#rubber-stamp-review), an approval that no longer shows that anyone checked the change closely. ## How does the review bottleneck form? The review bottleneck forms in six steps: 1. Coding agents open pull requests, including [background coding agents](https://specstory.com/learning/glossary#background-coding-agent) that work while nobody watches. 2. Each pull request waits in a queue until a reviewer who knows that part of the code is free. 3. Reviewers have a fixed number of hours, so the queue grows whenever pull requests arrive faster than reviews finish. 4. The main branch moves on while changes wait, so some of them need rework and a second review. 5. Reviewers catch up by reading faster, and each change gets a shallower check. 6. Days of fast reading wear reviewers down, which is called review fatigue, and tired reviewers catch less on the next change. [Approval fatigue](https://specstory.com/learning/environments/approval-fatigue) is the same pattern with a coding agent's permission prompts. Diagram: How the review queue forms The queue grows when pull requests arrive faster than the reviewer finishes them. Catching up by reading faster moves changes to the lower path. The queue depends on how many pull requests arrive and how long each one takes to read. [Pull request size](https://specstory.com/learning/code-review/pull-request-size) drives the reading time, because a long diff (the set of changed lines) takes longer to read and often gets a shallower reading. A team can see the bottleneck in three measures from its code host: - **Time to first review.** The wait between opening a pull request and its first review grows from week to week. - **Open pull requests.** The number of pull requests that wait for review keeps rising. - **Review comments for the diff size.** Large pull requests get approved with as few comments from human reviewers as small ones, which suggests that reviewers are skimming. ## What is an example of a review bottleneck? Here is an illustrative example. Acme Co. sells furniture online. One reviewer at Acme approves the pull requests that the team's coding agents open, and the week starts this way: 1. On Monday, the agents open 12 pull requests, and the reviewer has about 3 hours for review. 2. The reviewer reads 4 of them closely, at about 40 minutes each, and 8 wait overnight. 3. Background agents open 7 more overnight. On Tuesday morning, 15 pull requests wait for the reviewer's 3 hours, about 12 minutes each. 4. One of them answers the request "Let customers edit their delivery address during checkout." It changes 6 files, and its tests pass. 5. The reviewer reads the summary, scrolls through the diff for 5 minutes, and approves it. 6. After the merge, a customer with 2 items in the cart changes the address. The address saved, but the cart emptied. The reviewer did what the queue allowed. The approval recorded that someone looked at the change, not that anyone had run the checkout with items in the cart. One run of that workflow before review would have found the failure before a customer did. This example is simplified. A real team would also see pull requests that wait for days and conflict with the main branch. ## What changes when a coding agent writes the code? When a coding agent writes the code, more pull requests arrive, and each one can take longer to read. [A 2026 working paper](https://www.nber.org/papers/w35275) from the National Bureau of Economic Research (NBER) covered more than 500,000 GitHub developers. In that paper, AI coding tools up to and including autonomous coding agents raised commits by a cumulative 240%, but software releases by only about 30%. The authors link the gap to "human bottlenecks in the production chain." The paper does not measure review times, but its authors name code review among the human steps that limit output. On many teams, review is the main [human-in-the-loop](https://specstory.com/learning/ai-coding/human-in-the-loop) point for agent work, where a person approves the change before it takes effect. That reviewer is often the first person to read the code at all. The agent generated the diff and its summary, and the developer who asked for the change may not have read either. Code that merges without a run adds to [verification debt](https://specstory.com/learning/verification/verification-debt), even after a close reading. A routine for [reviewing agent pull requests](https://specstory.com/learning/code-review/reviewing-agent-pull-requests) checks the task and the test edits first, because coding agents often go wrong there. A team can also cap how many agent pull requests each developer has open at once. ## What are the limits of adding more reviewers? Adding reviewers shortens the queue for a while, but it has four limits: - **Knowledge is scarce.** A change to checkout needs a reviewer who knows checkout, and a reviewer from another part of the codebase usually reads more slowly and catches less. - **More readers do not run the code.** A second reader finds more problems in the source, but reading code and [running code](https://specstory.com/learning/verification/reading-vs-running-code) find different bugs. Acme's emptied cart showed up when a customer checked out with items in the cart. - **AI reviewers add comments, not hours.** [AI code review](https://specstory.com/learning/code-review/ai-code-review) can read each pull request quickly, but a person still reads its comments and approves the merge. - **Output keeps growing.** If agent output grows faster than the team does, extra reviewers slow the queue's growth but do not clear it. Some teams sort pull requests by risk instead, which is called risk-based code review. A change to checkout gets a close reading, and a documentation edit gets a quick look. That choice spends reviewer hours where a mistake costs most, but it does not show that the software works. ## How is the review bottleneck different from the CI bottleneck? In [continuous integration](https://specstory.com/learning/ci-cd/continuous-integration) (CI), shared machines build and test each change. The [CI bottleneck](https://specstory.com/learning/ci-cd/ci-for-coding-agents) is a queue for that machine time, while the review bottleneck is a queue for people's attention. Scaling CI usually means more machines, or running only the tests a change can affect. Neither adds an hour of reviewer time. The two queues overlap when a failed check sends a reviewed pull request back for fixes, because the fix then waits in both. ## How do you find failures before a change reaches review? Wait until the automated checks pass, then run the changed software on the branch before you request a review. Try the workflow the task describes, e.g. changing the address with items in the cart. Send a failure back to the coding agent as steps it can repeat. The reviewer can then spend more of the review on design and intent. Coding agents outpace testing, even with AI review. RunStory is in private alpha for CLIs and web apps. The alpha tests your software in isolated sandboxes. When something breaks, your coding agent receives the actions RunStory took and evidence of the unexpected result. Your team keeps the final release decision. [Join the RunStory alpha →](https://specstory.com/runstory#alpha) ## FAQs ### Is AI making code review slower? AI coding tools can make code review slower for a team, because coding agents can open more pull requests than reviewers can read. Changes then wait longer in the queue, or reviewers keep up by skimming. Each review can also take longer, because the reviewer is often the first person to read the code. ### What is a rubber-stamp review? A rubber-stamp review is a code review that approves a change without checking it closely. It often follows a long queue or a long diff. The approval then records that someone looked at the change, not that anyone checked what it does. ### How do you measure a review bottleneck? A review bottleneck shows up in data from the code host. Track the wait before a pull request's first review, the number of open pull requests, and comments from human reviewers compared with diff size. Longer waits show a growing queue, and large diffs approved with as few comments as small ones suggest that reviewers are skimming. ### What is risk-based code review? Risk-based code review sorts pull requests by how much harm a mistake in them could cause. People read the riskiest changes closely, e.g. checkout code, and give documentation edits a lighter check. Sorting by risk changes which pull requests get a close reading, but it does not show that the software works. --- Source: [Code review bottleneck | AI pull requests | SpecStory](https://specstory.com/learning/code-review/review-bottleneck)