Can't keep up with reviewing AI-generated pull requests? Shrink the queue first.

Our team can’t keep up with reviewing AI-generated pull requests. What now? Do not hire more reviewers first, and do not tell people to review faster. First, measure how many pull requests your qualified reviewers can really review in a week. Second, run every check that a machine can run before a human opens the diff. Third, limit the size of each pull request and name one owner for each. Last, close the pull requests that break these rules without a review. This order works because the cost to write code fell and the cost to verify it did not.

What is the short answer to the review backlog?

Most writing on this problem comes from open source maintainers. They receive pull requests from strangers. You have employees and a manager. You can set a rule and enforce it.

Why did review become the bottleneck?

Agents made writing code cheap. Review and integration did not become faster. The New Stack reports this pattern in its piece Open source maintainers are drowning in AI-generated pull requests. Enterprise teams are next. The headline says that company teams will see the same problem soon. Your team may already see it.

The cause is an old assumption. A pull request used to take hours or days to write. A few hours of review time did not change that cost much. Now an agent writes a diff in minutes. The review step takes the same time as before. I describe this change in momentum-driven code reviews. Diffs arrive in bursts. An agent also touches payments, auth and the build script in one change. The reviewer who is free is rarely the reviewer who knows that code.

The effort is not equal on both sides. I call one cause the slop grenade. A person adds a small amount of complexity with little effort, and the team pays for it in review, in maintenance and in on-call work. Read what is a slop grenade for details. The same gap sits behind the verification bottleneck. Writing software gets cheaper. Verifying it gets more expensive, because the volume of plausible code grows.

The Godot project states the same limit in plain words. Its 2026 contribution policy says “the number of qualified reviewers is small.” It also says “we can’t keep up with everything coming in.” It calls review “the largest bottleneck in the engine right now.” AI contributions add to a shortage that was already there. Your team has the same shortage, with fewer people.

How much review capacity does your team have?

Most teams never measure this number. A long queue does not tell you the capacity. Count it with the data in your Git host for the last four weeks.

First, list the people who can approve changes in each area of the code. A frontend engineer who approves a database migration is not a qualified reviewer. Second, count the reviews that each person finished each week. Third, measure the median time from “ready for review” to the first real comment. Fourth, ask each reviewer how many hours they can give to review without dropping their own work. Count only the people who would sign their name under the approval.

Then compare two numbers: the pull requests that arrive each week, and the pull requests that your qualified reviewers finish each week. If arrivals are higher, the queue grows without limit. You must reduce arrivals, reduce the work in each review, or add qualified reviewers. Hiring is slow. A new person needs months to learn the code. Thus the first two options give faster relief.

Set a work-in-progress limit for the review step. Let each reviewer hold at most two open reviews. Let an author open a new pull request only when a review slot is free. The limit moves the waiting time to the author, where it is cheap, and away from the reviewer, where it is expensive.

I built a small model to show what happens when reviewers cannot match the flow. It is a toy model with a fixed random seed. It is not a measurement of a real team. Agents send a stream of diffs, and about one in three has a defect that CI does not catch. You choose one of three reviewer types. The “LGTM reflex” reviews 64 diffs per day and catches 1 defect in 20. The “checklist” reviewer reviews 22 per day and catches about 1 in 2. The “trained eye” reviews 44 per day and catches 9 in 10. Press Run the day and then raise the load.

Watch the two counters, safe merges and escaped bugs. The reflex reviewer ships the most changes and leaks the most defects. The checklist reviewer catches more defects but leaves a backlog that is never reviewed. The trained eye is both fast and accurate until you raise the load. At high load, every profile fails in a different way. This is the reason to cut the load before you try to make people faster.

Which checks can run before a human looks?

Every minute a person spends on a problem that a machine can find is a lost minute. Build a gate that every pull request must pass before a human sees it. In my post on the 100x engineer myth, I call this system a harness. The harness holds the judgment of your team in code. It runs checks that cost no tokens and take milliseconds. It rejects bad work before a person reads it.

An AI reviewer is a filter. It is not an approver. The model that checks the work often shares the blind spots of the model that wrote it. A person still gives the final approval for any area with money, access control, data or migrations.

Write the gate as a required status check on the main branch. Make the failure message say what to fix. An agent can read that message and repair the change without help. The agent writes, the gate rejects, the agent corrects, and no human spends time on the cycle.

How small should an AI-assisted pull request be?

Small enough that one person can hold the whole change in their head. I do not give a single line count, because the right number depends on your code. Pick a limit from your own data. Look at the pull requests that your reviewers approved with real comments in the last month. Look at their size. That size is your limit. A reviewer gives thoughtful comments on a change of that size and rubber-stamps larger ones.

CodeRabbit describes what maintainers do under pressure in AI is burning out the people who keep open source alive. Some add stricter contribution templates. Some ask for smaller pull requests. A few temporarily restrict new contributors to control the queue. CodeRabbit sells AI code review, so read its framing with that in mind. The three measures are still sensible for a company team.

GitHub is also moving. InfoWorld reports that GitHub is weighing restrictions on pull requests to protect maintainers, with options that include limits on who can open them. A GitHub product manager wrote that maintainers spend “substantial time” on contributions that do not meet quality standards. The same article quotes a Microsoft Azure engineer and maintainer. He says that reviewing every shipped line by hand does not scale when AI writes the code. You can set your own limits today.

Ask the agent to split work into a stack of small changes. Each change should do one thing. Each change should have its own tests. A reviewer can then approve the first change and begin on the second. Large AI diffs hide risk in the middle, where nobody reads. Put generated files and mass renames in their own pull request, and mark them as generated.

I built justshowmediff to review AI-generated changes in the browser. A clean diff view helps. It does not replace the size limit.

The next figure shows why volume has a ceiling. It is a sketch of the argument, not a measurement. Drag the slider to increase the push.

Watch the two lines. Generated output rises in a straight line on the log-log chart. Finished software saturates near 2x and then turns over past 10x. The turn happens where verification stops keeping up. The lesson for review is plain. More pull requests per week does not mean more shipped features. Past your review capacity, extra volume adds only queue and risk.

What policy should a company team set?

Open source projects write policies for strangers. Your team needs a policy for colleagues. You do not try to keep out bad actors. You try to keep quality high and responsibility clear. I covered the research in should you ban AI-generated code. The study it uses looked at 281 AI policies in popular open source projects. It found that 83.3% permit or encourage AI in code contributions. It also found that 48.8% require contributors to disclose AI use. Most projects do not ban AI. Most of them set rules for how to use it.

For a company team, I suggest four rules.

Disclosure is not a punishment. It tells the reviewer where to look. I wrote in code review is the interview that polish used to correlate with care and no longer does. A tidy diff from an agent says nothing about whether anyone thought about the tenant check or the retry on a POST request.

Ownership matters more than disclosure. The rule is short: you can generate anything, and you own what you ship. If the author cannot explain a change, the change is not ready for review. This puts the first review on the author. The reviewer then checks the judgment of the author. The reviewer does not need to find every error alone.

Add a rule about routing. Send each pull request to the people who know that area. Do not send it to whoever is free. A fast review from the wrong person produces an approval with no value.

When should you close a pull request without review?

Close it when the cost of review is higher than the value of the change. A rule you apply the same way each time is kinder than an angry reply after hours of reading. State the rules in a contribution guide, so that nobody is surprised. Several open source projects close pull requests without review when they look unrefined. The policy research I cite above counts closing pull requests as the most common countermeasure, at 48.4% of the 188 it recorded. Your team can use the same tool with more courtesy.

Use this table to decide.

The author can open the pull request again after they fix the problem. Write the message once and reuse it. It states the broken rule and the next step.

Do not close a pull request because AI wrote it. The test is whether the author understands the change and whether it meets your rules. If you cannot tell whether a change took an agent one minute or a person six hours, how it was made stops mattering.

Our team can’t keep up with AI-generated pull requests. What now?

Count your real review capacity, then set the intake limit to that number. Run every automated check before a human reads a diff. Keep each change small, and give each one a named human owner who discloses AI use and shows proof that the code runs. Close the pull requests that break these rules without a review. Then watch the median time to first review each week. If you need an outside view on the gates or the policy, I do this work as a fractional AI CTO.