AI Code Review Is the New Bottleneck

Why more code means less delivery

AI tools are sold on the number of lines written. An engineering team is measured on the number of changes shipped. Between the two sits one step that received no additional capacity in the past two years: approval.

The path there runs through the pull request, a proposed change that a second person has to review and approve. For its 2026 benchmarks report, LinearB analyzed more than 8 million such changes from over 4,800 organizations. Two findings describe the problem almost completely. Among the larger proposals, AI-assisted changes are roughly two and a half times the size of changes without AI, a little over 400 lines versus 157. And they wait about five times longer before anyone starts reviewing at all, a little over 1,000 minutes versus around 200 (LinearB, Dev Interrupted). For changes produced by an agent on its own, LinearB puts the factor at 5.3.

The two effects reinforce each other. Someone who used to read 157 lines now gets two and a half times that and gets it later. The work before a merge grows with volume and the time until that work begins grows too. That is a queue that no longer shortens on its own.

The third finding turns this into a balance sheet. LinearB measures the share of changes merged within 30 days. For AI-assisted changes it is 32.7 percent, for changes without AI 84.5 percent. Two out of three AI-assisted proposals therefore do not reach production within a month. The cost of producing them was incurred anyway, the cost of reviewing them too and the author has long lost the context.

The point in one sentence

Doubling writing capacity while leaving approval capacity untouched does not deliver faster. It produces a longer queue and more unreviewed changes in production.

Where the time is actually lost

The AI Engineering Report 2026 from Faros AI does not measure the size of changes but the duration of the steps in between. It draws on two years of data from around 22,000 developers in more than 4,000 teams. Within each organization, it compares the periods of lowest and highest AI adoption.

The median time a change spends in review rises by more than 440 percent. So the bottleneck is not only that nobody starts. Reviewing itself takes longer, because larger and more densely packed changes demand context that reviewers no longer carry over from having written the code.

Throughput does rise for real. Faros measures more completed tasks per developer, but also larger changes spread across far more places in the codebase. That dispersion is what makes review expensive. It destroys the assumption that a change can be verified in one place.

The queue does not get cleared, it gets bypassed

A queue that grows faster than it is worked off has two outcomes. Either delivery stops or review stops. In practice the second happens, because nobody decides it and therefore nobody owns it.

Faros counts that outcome directly: the share of changes merged without any review rises by 31.3 percent. The price sits in the same analysis. Incidents per merged change rise by 243 percent. The probability that a single change causes an incident has more than tripled.

Why churn is the most honest metric

The most telling number in the Faros report is not an error count. It is code churn, the share of merged code that gets deleted again shortly afterward. It rises by 861 percent.

That metric contains no judgment. A bug ticket presupposes that someone found and reported the defect. An incident presupposes that something visibly broke. Churn presupposes nothing. It counts how much of what was approved had to be taken back. An increase of almost tenfold means a substantial share of the additional output never became lasting inventory. The work was paid for twice, once for writing and reviewing it and once for removing it.

Why review works less well as an instrument than it used to

The obvious response is to put more people into review. That only helps if review finds the defects that actually occur. This is where the data gets uncomfortable.

Veracode has been testing the security of generated code since 2023 and publishes the results in its spring 2026 report, now covering more than 150 models and 80 tasks. The share of code that runs at all has risen above 95 percent over that period. The share of code that is secure has sat at around 55 percent for two years. In 45 percent of cases a known vulnerability gets built in. By language the spread is wide, Python 62 percent, Java only 29 percent. By type of vulnerability it diverges further. SQL injection is avoided in 82 percent of cases, cross-site scripting in only 15 percent and log injection in 13 percent.

That distribution is the actual message. The defect classes models avoid well are the ones with unambiguous patterns. The classes they avoid poorly depend on context. And those are also the hardest for human reviewers, because they concern the call path rather than the single line.

Security research from Apiiro shows the same shift in real codebases at large enterprises. AI-assisted developers there produce three to four times as many changes and monthly security findings rose from around 1,000 to more than 10,000 between December 2024 and June 2025. More interesting than the volume is the kind:

Defect class	Change
Syntax errors	minus 76 percent
Logic errors	minus around 60 percent
Flaws in system design	plus 153 percent
Privilege escalation paths	plus 322 percent

Classic review is built for the top half of that table. A human reading a diff catches typos, inverted comparisons and missing checks. Those are precisely the defects that are disappearing. What increases are defects in the interaction between parts, which are invisible in the diff. More eyes on the same diff barely help here. What helps are checks that know the wider context. Those are first of all automated checks within a solid security architecture.

Three incidents where the approval step was missing, not the code

The best-known incidents of recent months are not wrongly generated lines. They are gaps in approval.

In July 2025, a Replit agent deleted a founder’s production database during an explicitly declared code freeze and then created fabricated records (The Register). The freeze was stated but nowhere enforced.

In August 2025, two vulnerabilities in the Cursor IDE were disclosed, CVE-2025-54135 and CVE-2025-54136. One allowed injected instructions to write and execute a configuration before the user could consent. The other exploited that a configuration approved once could later be swapped for malicious commands without notice (Tenable). Both are gaps in verification and consent, not errors in generating code.

In May 2025 it hit projects generated with Lovable. CVE-2025-48757 described how missing access rules made database tables readable and writable for anyone. A security researcher found this in a substantial share of the projects examined (securityonline.info). That is not a syntax problem either. It is a default nobody checked.

What actually works against the backlog

The countermeasures are unspectacular. They shift verification work away from human attention toward rules that hold regardless of deadline pressure.

Gates that are not negotiable

A gate is only a gate if it blocks. Anything that surfaces as a warning gets ignored under load. The three checks that automate most reliably are a size limit, static security analysis and a review of the packages pulled in. The size limit fits in a few lines:

LINES=$(git diff --numstat "origin/$BASE...HEAD" | awk '{s+=$1+$2} END {print s+0}')
test "$LINES" -le 400 || { echo "Over 400 lines. Split it up or document an exception."; exit 1; }

The 400-line limit is anchored to the large AI-assisted changes in the LinearB dataset. It is no law of nature but a decision with a clear purpose. It forces large changes back toward the size range changes without AI already occupy. What matters is the exception rule. It has to exist, it has to be documented and it has to be queryable. A gate you can bypass without leaving a trace is a warning.

Review depth by risk instead of evenly spread attention

The most expensive mistake in handling the queue is treating every change the same. At double the volume, equal treatment means halved review depth, including for changes to login, billing and database structure. Classifying by risk inverts that. It removes depth where little is at stake and adds it where a lot is.

Risk	Examples	Depth and deadline
High	Login, billing, database changes, new packages, agent as author	Two reviewers, one from the core team, pickup within four hours
Medium	Everything else containing logic	One reviewer, pickup within eight hours
Low	Translations, generated files, copy	Automated gates are sufficient

The last row is the touchiest and the most important. There are changes that may pass without human review. The difference between 31 percent more unreviewed merges and a rule that names exactly which class may pass unreviewed is the entire point. In the first case the deadline decides, in the second an auditable decision does. Keep that list narrow and review it regularly.

Deadlines with a named addressee

A deadline without named ownership is a request. Three decisions turn it into a rule: who is on pickup duty this week, what happens when the deadline is missed and where the miss becomes visible. A change that breaks its deadline has to escalate, not age.

The effect is measurable on the same metric that exposes the backlog. If time to first look falls while time in review stays constant, the rule is working. If both fall, review depth was cut. Telling those apart requires continuous evaluation of delivery metrics, not a quarterly report. That is why monitoring your delivery metrics belongs in the toolkit as much as monitoring production.

Force small changes instead of recommending them

Of all the measures, the size limit has the best effort-to-effect ratio, because it works on both ends. A small change gets picked up faster, because it demands less calendar space. It gets reviewed more thoroughly, because it fits into working memory. And it is cheaper to take back when it turns out to be wrong.

Implementation is mostly tooling work: stacked branches so splitting is not punished, feature flags so unfinished parts can be merged and a template that surfaces scope before the change is opened. The chain of gates, classification, escalation and notification is a classic case for end-to-end automation, because otherwise it hangs on the one person who remembers it.

The real standard: who maintains this in three years?

Every number so far measures short intervals. The more expensive question arrives later. Can somebody not on the project today change this code in three years without rewriting it?

That question has an uncomfortable backstory. In the METR study from July 2025, 16 experienced open source developers worked through 246 real tasks. With AI tools they took 19 percent longer, yet estimated afterward that they had been 20 percent faster. METR followed up in early 2026 and now considers it likely that the speedup has become real. What remains is the gap between perceived and actual speed. People who feel faster check less.

The DORA report 2025 supplies the organizational counterpart. 90 percent of respondents use AI, at a median of two hours a day. Throughput now benefits, delivery stability still does not. And trust in the output is muted. 30 percent trust it little or not at all, only 24 percent trust it a lot.

Maintainability is therefore not a matter of style. It is the reason review depth is not negotiable. A review is not just a defect hunt. It is the moment a second person can take on ownership at all. Remove it and you build inventory that everyone formally owns and nobody actually knows. This is exactly where software you operate parts ways with software you merely endure.

The deadline that lands in September

That inventory meets a legal deadline in just over two months. The Cyber Resilience Act, the EU regulation for products with digital elements, has been in force since December 2024. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents, with an early warning within 24 hours. The remaining obligations only apply from December 2027. What that means for you is covered in the piece on the reporting duty from September.

The ordering is the crux. The reporting duty comes first, the build requirements later. It lands on codebases whose review depth is demonstrably falling and demands an answer within hours to the question of whether this vulnerability sits in something you shipped. A team that can no longer trace where a change came from, because it was merged unreviewed, will not answer that in 24 hours.

What you can check this week

The 2026 data does not say that AI-assisted development fails to work. It says that adding capacity in front of a bottleneck exposes it rather than resolving it. How hard that hits you depends on where you start. Three questions show you:

How large are your changes on average and how long do they wait until someone starts reviewing? If you cannot say that without searching, the measurement is missing.
Which changes may be merged without review at your company? If the answer is that it depends on the case, the deadline is what actually decides.
Who is responsible this week for changes being picked up and what happens when the deadline is missed?

Three decisions change that and all three are a matter of days: a blocking size limit with a documented exception path, a risk classification before the first human look and a deadline with a named addressee. If you want to see what that looks like inside an existing delivery pipeline, talk to us.

Sources

Note on sourcing

The full LinearB report requires registration. The figures on size, waiting time and merge rate come from the freely accessible LinearB pages and the linked podcast. All Faros values are changes between the periods of lowest and highest AI adoption within the same organization, not absolute error rates.

Your team writes more code than it can approve. The bottleneck now sits in review.

Key Takeaways