The AI-era review queue problem

"Since the AI tooling rollout, your review queue depth has doubled. What do you do?"

What the question is actually testing

Whether you recognise it as expected rather than surprising. When generation gets faster, the bottleneck moves from writing to reviewing. Teams hit this in month two of adoption almost universally, and a lead who treats it as an anomaly has not thought about where the constraint was.
Whether you measure before acting. The obvious response is "add reviewers", which is a staffing answer to a systems problem.
Whether you know the throughput-versus-stability data. This is the specific case where celebrating a delivery metric hides a quality regression.
Whether your interventions scale. Human review does not scale with generation speed. Only automation does.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: say that this is expected, and why

"I'd start by saying this is the predicted outcome rather than a surprise. The constraint on shipping was never typing speed; it was review, testing and deployment. Making generation faster doesn't remove the constraint, it moves load onto it. So the queue doubling is the system telling us where the bottleneck actually is, which is useful information."

Framing it as a bottleneck shift rather than a problem does real work in the conversation, because the alternative framing ("the AI tooling caused a problem") produces a conversation about whether to roll it back, and that is the wrong conversation.

Then: the measurement, split by whether the PR was AI-assisted

Without the split I am guessing, and the split is the whole diagnosis.

MEASURE, split AI-assisted vs not:

  review queue depth          how many PRs waiting
  time to first review        how long before anyone looks
  total merge time            open to merged
  PR size distribution        lines changed, files touched
  review rounds per PR        how many back-and-forths
  reviewer concentration      is one person doing 60% of it?

AND the quality side, over the same period:
  change failure rate
  escaped defect rate
  revert rate
  incident count attributable to recent deploys

The pattern I would expect, and the thing to name:

AI-assisted PRs are typically LARGER and arrive FASTER.
  -> queue depth rises from arrival rate, not from reviewers
     getting slower
  -> and review effectiveness collapses past roughly 400
     lines changed, which is a well-established finding, so
     larger PRs are reviewed WORSE at the same time as there
     are more of them

Reviewer concentration is the metric most likely to reveal the real problem. If one senior engineer is doing most of the review, the queue is a single-person bottleneck and no amount of process change fixes it without redistributing.

Then: four counters, in order of leverage

Human review does not scale with generation speed. Only automation does, so the interventions have to shift load off humans rather than asking humans to do more.

1. CAP PR SIZE.
   Review effectiveness collapses past roughly 400 lines, and
   generated PRs are often large. A CI check that flags PRs
   over the threshold, with an override that requires a
   reason, is the highest-leverage single change because it
   attacks both the queue depth and the review quality at
   once.

2. RAISE TEST REQUIREMENTS ON GENERATED CODE.
   Tests are the check that scales when volume rises and
   human review does not. Coverage on the changed lines,
   plus explicit tests for the error and null paths, which
   is where generated code most often falls short.

3. REQUIRE AUTHORS TO EXPLAIN GENERATED CODE AS THEIR OWN.
   Stated as a policy: if you cannot explain why it works and
   what it does at the boundaries, it does not go up for
   review. This is both a quality gate and a learning one,
   and it addresses the failure mode where an author submits
   code they have not read.

4. LABEL AI-ASSISTED PRs.
   Not to stigmatise, but so reviewers calibrate their
   attention and so the measurement above is possible at all.
   The label is what makes everything else measurable.

Ordering matters: PR size first, because it is a mechanical change, it needs no behaviour change from reviewers, and it improves review quality and queue depth simultaneously. Adding reviewers is nowhere on the list, and saying so explicitly is part of the answer.

Then: the thing to raise unprompted with leadership

"The thing I'd bring to leadership without being asked is the two-sided data. AI adoption correlates with higher throughput and also with higher change failure rate and slower recovery. That's DORA's recent reporting, and it's correlational rather than causal, and the useful framing is that AI amplifies whatever the team already is: strong testing and fast rollback get faster, weak ones get faster at shipping defects.

So I'd pair every speed metric with a quality guardrail and report them together. Because if we report deployment frequency alone we'll celebrate a number that's getting worse underneath, and by the time change failure rate is visible we'll have shipped a quarter of defects."

Volunteering the risk before it is asked about is the move, and it is what converts the conversation from "the tooling caused a queue problem" to "here is how we get the throughput without the instability".

The line I would not cross

"I wouldn't lower the review bar to clear the queue. That's the tempting move because the queue is visible and the defects are not yet, and it converts a throughput problem into a quality problem that surfaces six weeks later as incidents. If the queue cannot be cleared at the current bar, the answer is fewer or smaller PRs, not looser review."

Where this goes wrong

Adding reviewers. A staffing answer to a systems problem. It works briefly, it consumes the capacity that was supposed to be freed by the tooling, and it does nothing about PR size or review quality.

Rolling back the tooling. Throws away a real throughput gain to fix a bottleneck that was always there and was previously hidden by the slower arrival rate.

Celebrating deployment frequency. The specific failure this question exists to test. Reporting the throughput metric alone during a tooling rollout means celebrating a number that is degrading underneath.

Treating it as a quality problem with the individuals. The people writing the PRs are using the tool they were given. The system produced this, and the interventions are systemic.

Lowering the review bar. Converts a visible problem into an invisible one that returns as incidents.

Not labelling AI-assisted PRs, which makes every measurement above impossible and leaves you guessing about which population is driving the change.

Interviewer follow-ups

"Isn't a 400-line cap just going to make people split PRs artificially?" Sometimes, and that is mostly fine: an artificially split PR is still reviewed in smaller pieces, which is where the effectiveness comes from. The genuine failure is a split that separates a change from its tests or breaks a logical unit, so the check should flag rather than block, with an override that requires a stated reason. And I would watch for the specific gaming pattern of a huge PR labelled "refactor" alongside a small "logic" one, because the review attention goes to the small one while the risk is in the large one.

"What if the reviewers say the generated code is fine and they're just overwhelmed by volume?" Then the data says so and the interventions change: if review rounds per PR and escaped defect rate are both flat while queue depth rose, it is purely an arrival-rate problem and the answer is capacity and batching rather than quality gates. I would want that measured rather than asserted, because "the code is fine, there's just more of it" is what everyone says and it is sometimes true.

"How do you handle a reviewer who is the bottleneck?" First establish it, because reviewer concentration is measurable and people's impressions of who reviews the most are usually wrong. If one person is doing 60 percent, that is a single point of failure regardless of AI, and the fixes are rotation, explicit ownership of areas so review is distributed by domain, and deliberately growing reviewers by pairing juniors with the bottleneck person on reviews. That last one is slow and it is the only one that actually changes the capacity.

"Your VP says the tooling isn't delivering the promised productivity gain." I would show the two-sided data rather than defend the tooling. Throughput is up, measurably; stability is down, measurably; and the net is currently unclear because we are trading one for the other. Then the specific plan to get the throughput without the instability, with a date to re-measure. That is a more credible conversation than either "it's working" or "it isn't", and it puts the question on the right axis.

"What if the AI-generated code is subtly wrong in ways review misses?" That is the risk that justifies the test requirement over the review requirement, because human review is worse at catching subtle correctness bugs in unfamiliar code than tests are at catching them at all. So: coverage on changed lines, explicit error and boundary path tests, and property-based tests where the domain allows. And I would treat "the author must be able to explain it" as a real gate rather than a slogan, because an author who cannot explain the code cannot review the review.

"Would you restrict which teams can use it?" No, and I would push back on that framing. The DORA framing is amplification: the tooling makes a team more of what it already is. So the useful intervention is on the practices that determine which direction that goes, which is testing, batch size and rollback speed, rather than on access. Restricting access is a control that looks decisive and addresses none of the mechanism.

Production evidence

DORA's recent State of DevOps reports on AI adoption report the throughput-up, stability-down pattern and frame AI as an amplifier of existing organisational characteristics. These are survey-based correlational findings and should be cited that way, which is itself part of a good answer.

The review-size finding that effectiveness declines substantially past a few hundred lines is long-established in code review research and is reflected in practitioner guidance from SmartBear's large-scale review study onward. The specific threshold varies by study; the shape does not.

Google's code review practices, published in their engineering practices documentation, recommend small changes explicitly and document review latency as a tracked metric, which is the practice this answer applies to a new cause.

GitClear's analyses of AI-assisted code report increases in code churn and duplicated code blocks in AI-assisted repositories, which is one data point on the mechanism behind the stability finding rather than a settled result.

The SPACE framework's argument that no single metric captures productivity is the reason for pairing throughput with a guardrail rather than reporting either alone.

Interview delivery note

Open by normalising it, because that reframes the whole conversation: "I'd start by saying this is expected rather than surprising. The constraint on shipping was never typing speed, it was review, testing and deployment. Making generation faster doesn't remove the bottleneck, it moves load onto it, so the queue doubling is the system telling us where the constraint actually is."

Then the measurement, with the split as the key: "Then I'd measure, split by whether the PR was AI-assisted, because without that split I'm guessing. Queue depth, time to first review, merge time, PR size distribution, review rounds, and reviewer concentration. And the quality side over the same period: change failure rate, revert rate, escaped defects."

Give the interventions with the reason for their ordering: "Four counters, and adding reviewers isn't one of them, because that's a staffing answer to a systems problem. Cap PR size first, because review effectiveness collapses past a few hundred lines and generated PRs are often large, so it attacks queue depth and review quality at once. Then raise test requirements on generated code, because tests are the check that scales when volume rises and human review doesn't. Then require authors to explain generated code as their own. Then label AI-assisted PRs, because that's what makes the measurement possible at all."

The unprompted move that lands hardest: "And the thing I'd bring to leadership without being asked is the two-sided data. AI adoption correlates with higher throughput and also with higher change failure rate. So I'd pair every speed metric with a quality guardrail and report them together, because otherwise we'll celebrate deployment frequency while a number underneath gets worse, and we'll find out six weeks later as incidents."

Close on the line: "The line I wouldn't cross is lowering the review bar to clear the queue. It's tempting because the queue is visible and the defects aren't yet, and it converts a throughput problem into a quality problem that surfaces as incidents. If the queue can't be cleared at the current bar, the answer is smaller PRs, not looser review."

The Staff & Team Lead Interview Reference