AI coding tools and a growing review queue: find out what your reviews are waiting for

Your developers use AI coding assistants or agents, changes arrive faster than before, and the review queue keeps growing. Before you buy more seats or a review product, find out what your reviews are actually waiting for. Three possibilities are worth checking first: nobody has started the review, the same changes keep going back to their authors, or a technical decision is unresolved and the review cannot close around it. Each one needs a different response, and a queue can hold more than one at a time or something this list does not cover. A backlog that appeared after AI adoption does not prove that AI created it.

If you have not yet traced a few changes from request through to customer availability, start there instead. Work that looks stuck in review is sometimes waiting on testing or a release decision.

Two words are worth separating, because the studies distinguish them. An assistant suggests or completes code while a developer writes it. An agent takes a task and produces a larger change with much less step-by-step human involvement. A pull request, or PR, is one proposed change submitted for review. Teams say "AI" for all of it, which hides the distinction you need when you look at your own queue.

What current research supports, and where it stops

Fiona Chen and James Stratton's working paper Artificial Intelligence in the Firm: Bottlenecks in Software Production, in the version dated 8 November 2026, studies 655 firms and 720,542 workers between January 2021 and August 2026. Two findings are relevant here. Agent adoption is associated with a larger gain in code output than in finished output, and with longer time from review submission to approval. Assistants show no significant review-delay effect in the same analysis.

Read the limits with the findings. This is a working paper, not settled peer-reviewed consensus, and the data come from consenting clients of one provider rather than a representative sample of companies like yours. The estimates come from comparing adopters with similar non-adopters over time, which only holds if those groups would otherwise have moved together. Firms that adopt agents early may differ in ways the comparison cannot see. Earlier press coverage quoted figures from an older version of the same paper; those numbers are not the current result, and you do not need any of them to act.

A separate NBER working paper by Mert Demirer, Leon Musolff and Liyuan Yang, Writing Code vs. Shipping Code, reports a related pattern among more than 500,000 GitHub developers with AI telemetry: measured activity gains shrink as you move from commits toward projects and releases. We read the abstract page, not the full paper. Note also that a release on GitHub is not the same as value reaching a paying customer; your own queue has at least one more gap after the merge.

Taken together, these support one modest claim: more generated code does not automatically become more delivered software, and the gap deserves a look. They do not identify your bottleneck, and neither of them says that AI caused the queue you are looking at this week.

Three review states worth ruling out first

Pick one service and a fixed recent window, say the last six weeks, and state your timezone and whether you count working days or calendar days. Your cohort is every change that became ready for review inside that window, including the ones still unfinished at your cutoff. Record anything that was already waiting before the window opened as carry-in, listed separately, so a long-stuck change from two months ago does not quietly distort a before-and-after comparison. Leaving out unfinished work hides the worst delays. If you cannot reliably tell which changes were AI-generated, call the set mixed rather than guessing.

For each change, record the purpose and customer outcome, the author, the responsible reviewer and a backup, the scope and risk, the linked tests and what the author personally verified. Then record the timestamps: ready for review after preparation was complete, the first substantive human review, each return to the author and each resubmission, approval, merge, production deployment, and customer availability if that is separate. A bot comment or an automatic approval is not a first substantive review. Where a timestamp is missing, write unknown.

For every interval where the change sat still, also write down why it was blocked, what was missing at that moment, and who could actually have resolved it. The responsible reviewer may not have authority to settle a permission rule. If that is what blocked the change, record who can make the decision. For anything still open at your cutoff, record its age and what it is waiting for now.

Those timestamps give you elapsed time, not effort. A change can sit for four days while its reviewer is doing other necessary work, and you cannot read reviewer hours out of a board history. Do not count an interval twice when the author and reviewer were both active on it.

Now look at what you have. The three states below are the ones worth ruling out first; they are a starting diagnostic rather than a complete list, and a single change can sit in more than one.

The change is ready and nobody has looked at it

Ask whether the change has a capable owner, an agreed response time and coverage across the time zones your team works in.

If it does not, assign an owner and a backup, protect review time at natural breakpoints in the day rather than interrupting every focused task, and stop starting more discretionary work than the team can responsibly finish. Google's Speed of Code Reviews guidance separates a fast first response from completing the whole review, and its one-business-day response guideline is one team's local policy, not a universal target.

The boundary matters. Do not drop a required specialist or security approval to shorten this wait, and accept that you may genuinely be short of reviewers. This state is the one where more capacity is a credible answer.

The change keeps coming back to its author

Ask whether the author can explain the intent, the behavior and the evidence before handing the change over. If they cannot, the reviewer ends up performing the author's verification for them, one comment at a time. That can happen whether the code came from an agent, an assistant or the author's own hands; what matters is the missing explanation in front of you, not where the lines originated.

Require a short note with each change covering purpose, tests and risk, written by the person submitting it. Keep each change independently understandable with its related tests, in the spirit of Google's Small CLs guidance, which is explicit that size is a judgment with exceptions rather than a line limit you can publish. Move automated checks, such as linting, type checks and repeatable tests, ahead of human review.

The boundary: passing checks and an AI-written summary cannot establish that the change does the right thing for the business, and splitting a change must preserve safe integration and release behavior. You also keep the accountability either way. That is the same argument as deciding how much control to delegate to an agent in any other workflow.

Review starts promptly and then stalls

Ask what decision or expertise is actually missing. Is the review holding an architecture question, a permissions rule or an unclear requirement that no reviewer has the authority to settle inside a comment thread?

Resolve the decision before generating more code against the assumption, and pair the author with a qualified reviewer for that specific call. Fred Hebert's Embracing the Code Review Bottleneck, published 22 July 2026, describes a small team reviewing plans and prompts before implementation and perceiving better shared understanding without an obvious loss of speed. They later relaxed the strict form because not every task needed it. That is a first-person account rather than a measured result, and it is a useful reminder that review provides assurance you may not want to remove.

The boundary: expert time has an opportunity cost, and a faster approval that skips a real judgment is not a fix.

One aging pull request, three explanations

Here is a fictional example, written to show the distinction rather than to report a client. A SaaS team, meaning a company whose software customers use over the web rather than install, adds a permission change so that account administrators can grant read-only access to an external auditor. An agent produced most of the code. The pull request has been open for several days.

That single symptom has at least three explanations, and they are not distinguishable from the board.

The named reviewer is on leave and no backup was agreed, so nothing has been looked at. That is an ownership decision, and no change to the code will help.

Or the review began, and it keeps returning because there is no test showing that a revoked auditor loses access, and the author cannot say whether the change affects existing admin roles. That is author preparation, and adding reviewers will mostly spread the same rework around.

Or the review started immediately and stopped at a real question: should an auditor invited by one tenant, meaning one customer account whose data is kept separate from every other customer's, ever resolve to records shared with another tenant? Nobody has decided. That is an accountable design decision that needs the person who owns it, and when the same cross-system question returns across several changes it is worth an architecture review rather than another round of comments.

Notice that no numbers were needed to tell these apart. You need the reason each interval existed and who could have ended it, which is why the recording step above asks for the blocker, the missing evidence or decision, and its current owner alongside the timestamps.

Test one response, and keep the costs visible

Change one thing. If the first state accounts for most of what you recorded, assign a reviewer and a backup with protected review time for one service, for a fixed period such as two working weeks, and keep every existing review requirement intact.

Then compare similar work before and after, keeping the unfinished items in view. Track review delay, repeated returns to the author, production delivery and defects together, because improving the first while quietly worsening the others is not progress. Write down anything else that changed in the same period: staffing, incident load, scope, and tooling. Report what you observed without claiming the change caused it. A short before-and-after comparison on one team is not a controlled experiment.

Stop or revise the change if defects start reaching customers, if the delay simply moves into testing or release, or if it removes assurance you actually needed. And if the queue stays long while every reviewer is already fully committed to review work, you have evidence for the capacity argument you did not have at the start.

Resist two shortcuts along the way. A pull request count hides scope, risk, expertise and rework, so a PRs-per-reviewer target will mislead you. And a sample of completed changes hides the ones still stuck, which are usually the ones you care about.

Your next action is small: take the ten oldest open changes on one service, and write down for each one what it is waiting for, what is missing and who could resolve it. That is triage, not a survey. The oldest ten show you where the worst delays are and what kind of problem they are; they will not tell you how common each state is across the whole queue, which is what the fuller recording window above is for. If the answer turns out to span staffing, process ownership and architecture at once, a fractional CTO can work through that decision with you.