TL;DR
When coding agents let a team open pull requests faster than reviewers can finish them, the queue grows every day, however carefully people review. Before adding reviewers or a review bot, time a small sample to learn whether changes sit waiting or are slow to read. Then make authors finish the work a reviewer would otherwise do, cap open changes per author, keep changes small and give the queue an owner. Judge the result by waiting time, rework and escaped defects together.
A queue that grows however carefully people review
A review queue follows simple arithmetic. With illustrative numbers: if a team opens twelve pull requests a day and its reviewers finish nine, three join the backlog every day. Reviewing more diligently does not change that sum. Only three things do: how many changes arrive, how much reviewer time each needs, and how many hours people spend reviewing. Coding agents raise the first without touching the other two.
Two public questions show what that looks like from each side. In March 2026 someone asked on Hacker News how to manage review fatigue from coding agents. Their agents produced a large volume of pull requests, and checking architectural alignment and logic had made review a severe bottleneck. A month earlier, a consultant asked on Software Engineering Stack Exchange what to do about a colleague they believed was passing review comments straight to an assistant. Each round took the reviewer five to twenty minutes to understand code its author had not read, questions came back as rewritten code instead of answers, and the cycle repeated. One is about volume, the other about a reviewer quietly doing the author's work. Most teams have some of both.
DORA's 2025 report on AI-assisted development, based on nearly 5,000 technology professionals, found that AI adoption now goes with higher delivery throughput while delivery instability continues to rise (InfoQ's report on DORA 2025), and it describes AI as an amplifier of the strengths and dysfunctions an organisation already has (DORA 2025). That is a survey correlation, not a measurement of your queue.
Find out where the review hours go
Before changing any rules, find out which of two problems dominates; many teams have both. In a queue problem, changes wait a long time before anyone opens them. In a review-cost problem, each review is slow once it starts or needs several rounds. They need different fixes; a review bot added to a queue problem mostly adds comments.
A small sample is enough to tell them apart:
- Take the next 20 to 30 pull requests marked ready for review, agent-assisted or not, and follow each whether it merges or not: when it was marked ready, first reviewed by a person, and merged or closed, plus its review rounds and the lines and files it changed. Count the open, unreviewed backlog at the start and end as well; sampling only merged changes hides the ones that are stuck or abandoned.
- Ask reviewers to log their active minutes on those reviews in three buckets: working out what the change is for, reading the diff, and chasing evidence the author did not supply (how it was tested, what else calls this code).
- Note which of them came back in the following weeks as a revert, a hotfix or a related bug.
- Compare waiting time with active time. If most of a pull request's life is spent waiting, the queue is the likely constraint. If active time is high and the third bucket is large, reviewers are probably absorbing work the author skipped.
The minutes are self-reported and the sample small, so read the result as a direction, not proof of a single cause. Published data suggests looking at size first. A study of 33,707 agent-authored pull requests in the AIDev dataset found that patch size and the number of files touched predicted review effort far better than the pull request's description did, and that the 28.3% merged instantly were mostly narrow changes (Early-Stage Prediction of Review Effort in AI-Generated Pull Requests, January 2026). Its effort measure counts reviews and comments, including bot messages, not reviewer time, so your own minutes are still worth collecting.
Make the author finish before the queue starts
The third bucket, chasing missing evidence, is the cheapest to remove, because the author or their agent can supply it before anyone else spends time. Agree a short definition of ready and keep pull requests in draft until it is met. On GitHub that has a mechanical effect: code owners are not automatically asked to review a draft pull request, only once it is marked ready (GitHub code owners).
- Intent linked. The ticket or decision the change implements, so the reviewer does not reconstruct it from the diff.
- One concern per pull request. Refactoring, generated files and behaviour changes are split, or at least listed separately.
- What was run. Tests, lint and build ran in CI or with a recorded command, rather than "tests pass" in a generated summary.
- What was not checked. Untested paths, assumptions, and files the agent changed that the author has not read.
- Risk named. Migrations, shared code, configuration and anything hard to roll back are pointed out, with a note on how to undo it.
- The author can answer for it. Review questions get an answer in words before a new push, without going back to the agent.
The last item speaks to the Stack Exchange case. When a question comes back as rewritten code, the reviewer starts again on a diff nobody has explained. Asking for the answer first keeps review a conversation between two people who understand the change. The article on what an AI-assisted pull request should include covers what an author should hand the reviewer.
Match work in progress to reviewer capacity
Once changes arrive ready, the remaining levers are how many arrive at once and how big they are.
- Cap open pull requests per author. With a limit of two or three ready changes per person, a busy author helps review before opening another.
- Keep changes small from the start. Google's engineering practices say 100 lines is usually a reasonable size for a change and 1,000 lines usually too large, and that small changes are reviewed more quickly and more thoroughly (Google: small changes). Ask the agent for a sequence of changes when the work is planned; splitting a finished branch afterwards is harder. The article on stopping a coding agent changing unrelated code shows how to hold each change to a declared scope.
- Give the queue an owner. Rotate a reviewer of the day who picks up new pull requests first, and use code owners so specialist areas reach the right person. Google's guidance treats one business day as the maximum time to respond to a review request, and tells reviewers not to break off focused work to do one (Google: speed of code reviews).
- Decide what automated review is for. A model review can catch mechanical problems first, but it is a second opinion from the kind of system that may have written the code. GitHub's documentation says Copilot's reviews do not count toward required approvals by default, that this can be switched on, and that Copilot is not guaranteed to spot every problem (GitHub Copilot code review). Keep a human approval required for agent-written changes unless your own measurements justify something else.
Judge the change by speed and stability together
After a month, repeat the sample and read the measures as a set, because each can improve for the wrong reason:
Comparison
| Measure | Improvement looks like | A warning sign |
|---|---|---|
| Time from ready to first review | Falls | Falls while review rounds rise |
| Active review minutes per change | Falls, mostly in the missing-evidence bucket | Falls because reviewers skim |
| Review rounds per change | Fewer | Unchanged although changes are smaller |
| Changes reverted, hotfixed or reopened after merge | Flat or lower | Rising |
| Open pull requests per reviewer | Stable | Climbing week on week |
DORA's change fail rate and deployment rework rate are the delivery-level versions of the fourth row, and DORA advises using its metrics to improve one team's performance over time rather than to compare teams (DORA metrics). Ask reviewers too: a shorter wait that comes from reviewing in the evening is not an improvement.
Paqad works on the author side of this list. Every change passes review and checks stages that leave records in its evidence bundle: review starts from a machine-built digest of known findings and records a rollback plan, and the checks run your project's own format, test and build commands. The change ends with one receipt, Safe to merge, Needs your attention or Inconclusive, which paqad-ai deliver can post on the pull request once CI is green. For riskier changes, on Paqad's graduated and full lanes in Claude Code and Codex CLI, each stage runs as a separate agent. The recorded review is still a model's judgement rather than independent proof, Safe to merge means the gates passed, not that the code is correct, and the receipt does not authorise a merge; whether it shortens your reviews is for the sample above to show. Paqad's stage agents page lists which stages run on their own and what each one is allowed to do.
Frequently Asked Questions
How can our team keep up with code review when AI produces pull requests faster than we can review them?
Treat it as a capacity problem: cut the reviewer time each change needs and the number of changes open at once before adding people or tools. Another qualified reviewer adds review hours, so the team can finish more changes, not only start them sooner; it pays off most when waiting dominates. An AI reviewer helps mainly with the mechanical part of reading.
Where is review time going: understanding intent, reading the diff or checking missing evidence?
Often in the part nobody logs: rebuilding the context the author already had. A quick test is to ask a reviewer to state the purpose of a change in one sentence after reading only its description. If they cannot, intent is costing time before the diff is even opened.
What should authors complete before a pull request enters the review queue?
Besides the ready checklist, a self-review in the pull request tool: the author leaves comments on their own diff at the places a reviewer should look first. It costs the author a few minutes and shows the reviewer where the risk sits.
How should task size, review ownership and work in progress change to match reviewer capacity?
Size the work when the ticket is planned, not when the diff arrives: if a ticket will clearly produce more than one reviewable change, split the ticket. For ownership, make sure at least two people can approve each area where agents work heavily, so reviews do not wait on one person's absence.
What measures would show faster delivery without more escaped defects or reviewer overload?
Choose a guard measure before you change anything, for example that reverts and hotfixes within 30 days of merge must not rise while waiting time falls. Picking it afterwards invites reading only the numbers that improved.