Here is a pair of numbers that should bother you. In Faros AI's 2026 engineering report, teams with high AI adoption complete 33.7% more tasks and merge 16.2% more pull requests than teams with low adoption inside the same organizations. Deployments per week went down 11.7%.
More work finished, more work merged, less work shipped. Most commentary treats that as a quality problem: AI code is sloppy, so it gets stuck. Some of it is. But I think the bigger effect is plainer and older than any language model. Your review process is a queue, queues have a cliff, and AI adoption moves you toward the edge from three directions at once.
If I am right, "write better prompts" and "add an AI reviewer" are both the wrong first move. The first move is to find out how close to the cliff you already are.
The numbers, with their caveats
The Faros AI Engineering Report draws on about 22,000 developers across roughly 4,000 teams, with two years of telemetry. It compares high and low AI adoption inside the same organizations. The page does not define the cutoff between the two, and the full methodology sits behind a download form, so treat every figure below as a vendor's telemetry, not a controlled experiment.
With that said, the shape is striking. Pull request size is up 51%. Median review time is up about 5X. Incidents per pull request are up 242.7%, roughly 3X. Code churn is up 861%. And the delivery number at the bottom of the list, deployments per week, is down.
A companion post from Faros adds the review-side detail: median time in PR review up 441.5%, pull requests merged without any review up 31.3%, and a quarter of pull requests now reviewed by an AI agent. That last figure is up from zero the year before. One caveat the post itself leaves unstated: the 31.3% is a change in the rate of unreviewed PRs, not the share of all PRs that skip review.
Notice what is missing from that list. Nothing says developers got slower at writing code. Everything that got worse sits downstream of the keyboard, in the part of the pipeline where a human has to read, understand, and approve.
Review is a server, and servers have a utilization curve
A reviewer is a server in the queueing-theory sense. Pull requests arrive, wait, get served, and leave. The one number that governs how long they wait is utilization: the fraction of reviewer time already spoken for.
The classic result for a single queue with random arrivals and random service times says wait time scales with utilization divided by one minus utilization. At 50% utilization that ratio is 1. At 80% it is 4. At 90% it is 9. At 95% it is 19. The line is flat for a long time and then it is not a line anymore.
This is why review delays feel sudden. Nobody's process got worse over a quarter. The team crept from 55% to 70% to 85% utilization, each step felt fine, and by the end everyone's wait was nearly five times what it had been at 55%.
AI adoption pushes utilization up through two separate levers. Arrival rate rises because more tasks complete: Faros reports 33.7% more. Service time rises because each pull request is bigger: 51% bigger by their measure, and a bigger diff takes longer to read. Utilization is arrival rate times service time divided by the number of reviewers, so the two effects multiply. A third lever is hiding in the reviewer pool itself: the people qualified to review the risky changes are the senior engineers, and their hours are the part of the system that did not scale.
A simulation you can run
I did not want to hand-wave this, so I wrote a small simulation. Three reviewers, each giving two focused hours a day to review. Pull requests arrive at random, each takes an average of 30 minutes to review with exponentially distributed variation, and the first free reviewer takes the next one. Here is the core of it:
import random, statistics
def sim(arr_per_day, svc_hours, reviewers=3, hours_per_day=2.0, n=200000, seed=7):
random.seed(seed)
lam = arr_per_day / hours_per_day # arrivals per review-hour
free = [0.0] * reviewers # when each reviewer is next free
t, waits = 0.0, []
for _ in range(n):
t += random.expovariate(lam)
i = min(range(reviewers), key=lambda k: free[k])
start = max(t, free[i])
waits.append(start - t)
free[i] = start + random.expovariate(1 / svc_hours)
waits.sort()
return statistics.mean(waits), waits[int(.5 * n)], waits[int(.9 * n)]The baseline is five pull requests a day at 30 minutes each. Then I applied the two Faros multipliers: 33.7% more arrivals, then 51% longer service time on top. These are the results I got running it, with wait time converted from review-hours into working days at two review-hours per day:
At the baseline of five pull requests a day, utilization is 0.42, the mean wait is 0.02 days, and the 90th percentile wait is 0.06 days. With 33.7% more pull requests, utilization is 0.56, the mean wait is 0.06 days, and the 90th percentile is 0.21 days. With 33.7% more pull requests that are also 51% bigger, utilization is 0.84, the mean wait is 0.56 days, and the 90th percentile is 1.55 days.
Read those together. Adding a third more work roughly tripled the wait, which nobody would panic about because 0.06 days is under an hour. Then making each item half again as large multiplied the mean wait nearly tenfold and pushed the slow tail past a day and a half. Utilization went from 0.42 to 0.84. It did not double the pain. It took it up by a factor of about 28 on the mean.
This is a toy. Real review work is not exponentially distributed, reviewers get interrupted, and pull requests are not independent. I am not claiming this model reproduces Faros's 5X median figure, and the numbers above are not Faros's numbers. The claim is narrower: a modest-looking increase in load can produce an enormous increase in wait when you start from a utilization that felt comfortable. The direction matches what the telemetry shows, and the mechanism needs no one to have written worse code.
What the queue does when it overflows
A saturated queue does not just get slower. It changes behavior, and the behaviors it picks are bad ones.
Reviewers triage by skimming, because reading everything is impossible. Authors respond to long waits by batching more into each pull request, since a review cycle is now expensive, which makes the next diff bigger and the utilization worse. Teams quietly approve things they do not understand to clear the backlog, which is where the 31.3% rise in unreviewed merges starts to look less like negligence and more like a pressure valve. And the bugs that slip through show up later as incidents, which are served by the same senior engineers who were supposed to be reviewing, closing the loop.
One data point on what leaks through. A large empirical study of AI-authored commits from researchers at Singapore Management University looked at 302,579 commits from 6,299 public GitHub repositories, spanning Copilot, Claude, Cursor, Gemini, and Devin. It found 484,366 static-analysis issues introduced by those commits, and 22.7% of the tracked issues were still present at the latest revision. Most were code smells, so the typical leak is not a catastrophe. It is a steady drip of things nobody had time to object to. The study has no human-written baseline, so it cannot tell you AI code is worse than human code, and its authors say as much. It does tell you that review did not catch everything it could have.
The yes, but
The strongest objection is that AI can review too. Faros says a quarter of pull requests already go through an AI reviewer, and an automated first pass is cheap. If the machine reads the diff, the senior engineer's utilization drops, and the cliff moves away.
That is true for some of the load. An AI pass catches style issues, obvious bugs, and missing tests, and every one of those it catches is service time a human no longer spends. I use that argument myself.
But the same report that counts the AI reviewers also shows review time up 5X and unreviewed merges up. The AI pass is a filter in front of the queue, not a second server behind it, and a filter only helps if what gets through is easier to review. Logic errors, wrong assumptions, and a change that is correct but does not belong in this codebase are exactly the findings that still need someone who knows the system. There is also a fair measurement objection: Faros is a vendor with a product to sell in this area, the adoption cutoffs are undefined, and one figure in the companion post (bugs per PR) is reported differently on the two pages. I would not stake a budget on any single percentage. I would stake one on the shape of the curve, because the shape comes from arithmetic and not from a dataset.
What to do on Monday
Measure your utilization, not your velocity. You need three numbers per week: pull requests opened, median review minutes of actual reading per pull request, and reviewer hours available for it. Multiply the first two, divide by the third. If the answer is above about 0.7, you are on the steep part of the curve and nothing you do to the prompt will help.
Then pull the levers in the order the math suggests. Cap pull request size first, because it is the lever you fully control and it acts on service time directly. Widen the reviewer pool second, by deliberately training mid-level engineers on the risky parts of the system. Automate the cheap checks third. Only then ask whether the AI reviewer is worth its false positives.
And put deployments per week next to tasks completed on the same dashboard. If one is rising while the other falls, you are not seeing a productivity gain. You are watching a queue fill up.
