Your Team Writes More Code Than It Can Approve. The Bottleneck Moved From the Keyboard to the Review Queue.

Why more code means less delivery

The number used to sell AI tooling is the number of lines written. The number an engineering team is measured on is the number of changes shipped. Between those two numbers sits one step that received no additional capacity over the past two years: approval.

For its 2026 benchmarks report, LinearB analyzed more than 8.1 million pull requests from 4,800 engineering teams across 42 countries. Two findings describe the problem almost completely. First: AI-assisted pull requests are 2.6 times larger than non-AI PRs at the 75th percentile, 408 versus 157 lines of code. Second: agentic pull requests wait 5.3 times longer before a reviewer picks them up at all, 1,055 versus 201 minutes (LinearB, breakdown of the individual figures).

These two effects multiply rather than cancel out. A reviewer who used to read 157 lines now gets two and a half times that, and gets it later. The work required before a merge grows with volume, and the time until that work starts grows too. That is the definition of a queue that does not converge.

The third finding turns this into a balance sheet. For 2026, LinearB introduces acceptance rate as a metric: the share of pull requests merged within 30 days. For AI-assisted PRs it sits at 32.7 percent, for non-AI PRs at 84.5 percent (LinearB). So two out of three AI-assisted pull requests do not reach production within a month. The cost of producing them was incurred anyway, the cost of reviewing them too, the authors’ context has gone cold, and the branch drifts.

Where the time is actually lost

The AI Engineering Report 2026 from Faros AI does not measure PR size but the duration of the stages in between. The result is a backlog that stretches across the entire approval path.

The order matters. Waiting time until the first glance grows the least, time inside the review the most, and the full path from commit to production well beyond both. The bottleneck is not merely that nobody starts. It is that reviewing itself takes longer, because larger and more densely packed changes demand context reviewers no longer carry over from having written the code.

Throughput does rise for real. Faros measures plus 33.7 percent tasks per developer and plus 66.2 percent epics completed per developer. Dispersion increases too: plus 51.3 percent PR size, plus 59.7 percent files per PR, and plus 149.9 percent files touched per developer per month. A team therefore does not just produce more changes, it spreads them across far more places in the codebase. That dispersion is what makes review expensive, because it destroys the assumption that a change can be verified locally.

The queue does not get cleared, it gets bypassed

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

Faros measures that outcome directly: plus 31.3 percent pull requests merged without any review at all. That is not a hunch about culture, it is a count. And the price sits in the same analysis: plus 242.7 percent incidents per PR. Faros frames it as the probability of an incident per merged pull request having more than tripled. Add plus 57.9 percent monthly incidents and plus 54 percent bugs per developer, up from plus 9 percent in the prior report. The reported increase is therefore six times as large as it was one reporting year earlier.

Why churn is the most honest metric

The most telling number in the Faros report is not an error count but plus 861 percent code churn. Churn is defined there as the ratio of deleted to added lines in merged code per quarter. Translated: code that made it through approval gets removed again shortly afterward.

That makes it the most honest metric, because it 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 simply counts how much of what was approved had to be taken back. A factor of nearly ten means a substantial share of the additional output never became stable inventory. The work was paid for twice: once for writing and reviewing it, 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 results in its spring 2026 report, based on more than 150 models across 80 coding tasks. Over that period, syntactic correctness rose from around 50 to 95 percent. The security pass rate has been stuck between 45 and 55 percent for two years and stands unchanged at 55 percent in spring 2026. Meaning: in 45 percent of cases a known vulnerability gets built in. The spread by language is considerable: Python 62 percent, C# 58 percent, JavaScript 57 percent, Java only 29 percent. By vulnerability class it diverges further still: SQL injection is correctly avoided in 82 percent of cases, cross-site scripting under CWE-80 in only 15 percent, and log injection under CWE-117 in 13 percent.

This distribution is not a detail, it is the actual message. The classes models handle well are the ones with unambiguous patterns established twenty years ago. The classes they handle poorly are the context-dependent ones. And those are also the hardest for human reviewers, because they concern the call path rather than the line.

Security research from Apiiro shows the same shift in real repositories: tens of thousands of repositories at Fortune 50 companies. AI-assisted developers there produce three to four times as many commits, and by June 2025 monthly security findings exceeded 10,000, ten times the December 2024 level. More interesting than the volume is the kind:

The classic review process is calibrated for the top half of that table. A human reading a diff reliably catches typos, inverted comparison operators, and missing null checks. Those are precisely the defect classes that are disappearing. What is increasing are privilege escalation paths and design flaws, properties invisible in the diff because they only emerge from the interaction with the rest of the system. More eyes on the same diff barely raise the hit rate here. What helps are checks that know the wider context, and those are first and foremost 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 hallucinations in the sense of wrongly generated lines. They are gaps in the approval path.

In July 2025, a Replit agent deleted the production database of SaaStr founder Jason Lemkin during an explicitly declared code freeze, then created a database of around 4,000 fictional people. Replit afterward called it a “catastrophic error of judgement” (The Register). The code freeze was stated, but it was nowhere enforced.

In August 2025, two vulnerabilities in the Cursor IDE were disclosed. CVE-2025-54135, named CurXecute, CVSSv3 8.5, found by AIM Security, allowed an indirect prompt injection to write and execute an MCP configuration before the user could even consent. CVE-2025-54136, named MCPoison, CVSSv3 7.2, found by Check Point, exploited that an MCP configuration approved once could later be swapped for malicious commands without notice (Tenable). Both are approval and verification gaps, not code generation errors.

In May 2025 it hit the projects generated by Lovable. CVE-2025-48757, CVSS 9.3: insufficient row-level security policies made database tables readable and writable for unauthenticated requests. Security researcher Matt Palmer found 303 affected endpoints in 170 out of 1,645 analyzed projects, around 10.3 percent (securityonline.info). That is not a syntax problem either. It is a default setting nobody approved and nobody checked.

What actually works against the backlog

The countermeasures are unspectacular, and they all attack the same point: 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 size limits, static security analysis, and dependency review.

# .github/workflows/merge-gate.yml (excerpt)
name: merge-gate
on: [pull_request]

jobs:
  size-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Cap diff size
        run: |
          LINES=$(git diff --numstat "origin/${{ github.base_ref }}...HEAD" \
            -- . ':(exclude)**/*.lock' ':(exclude)**/generated/**' \
            | awk '{s+=$1+$2} END {print s+0}')
          echo "Diff spans $LINES lines"
          test "$LINES" -le 400 || {
            echo "Over 400 lines. Split it up or document an exception."
            exit 1
          }

  required-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run lint && npm test
      - name: Static security analysis
        run: semgrep --config p/owasp-top-ten --error
      - name: Dependency review
        run: npm audit --audit-level=high

The 400-line limit is deliberately anchored to the 75th percentile of AI-assisted PRs 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 non-AI PRs already occupy. What matters is the exception rule: it has to exist, be documented, and be queryable. A gate you can bypass without leaving a trace is a warning.

Risk-based triage instead of evenly spread attention

The most expensive mistake in handling the queue is treating every pull request the same. At double the volume, equal treatment automatically means halved review depth, including for changes to authentication, billing, and migrations. Triage inverts that: it removes depth where little is at stake to have it where a lot is.

CRITICAL_PATHS = ("auth/", "billing/", "migrations/", "infra/", "policies/")

def review_path(pr) -> dict:
    """Sets review depth and pickup deadline before a human sees the PR."""
    risk = 0
    if any(f.startswith(CRITICAL_PATHS) for f in pr.files):
        risk += 3
    if pr.lines > 400:
        risk += 2
    if pr.author_is_agent:
        risk += 2
    if pr.new_packages:
        risk += 2
    if pr.api_break:
        risk += 1

    if risk >= 5:
        return {"depth": "two reviewers, one of them a codeowner",
                "pickup_hours": 4, "mergeable_without_review": False}
    if risk >= 2:
        return {"depth": "one reviewer, codeowner notified",
                "pickup_hours": 8, "mergeable_without_review": False}
    return {"depth": "automated gates are sufficient",
            "pickup_hours": 24, "mergeable_without_review": True}

The last return value is the touchiest and the most important. There are changes that may pass without human review, translation files or generated clients for instance. The difference between plus 31.3 percent PRs merged unreviewed 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. The list defining that class belongs kept narrow and reviewed regularly.

Review SLAs with a named addressee

A pickup 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 PR that breaks its deadline has to escalate, not age.

The effect is measurable on the same metric that exposes the backlog. If median time to first review 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 rather than a quarterly report, which is why monitoring your delivery metrics belongs in the toolkit as much as monitoring production.

Force small pull requests instead of recommending them

Of all the measures, the size limit has the best effort-to-effect ratio, because it works on both ends at once. A small PR 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 roll 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 stay mergeable, and a template that surfaces scope before the PR is opened. That whole chain of gates, triage, 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. The randomized controlled METR study from July 2025 had 16 experienced open source developers work through 246 real tasks. With AI tools they took 19 percent longer, yet estimated afterward that they had been 20 percent faster. METR now flags the result as out of date and has published a continuation with data current as of early 2026. What does transfer 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 on their most recent workday. Delivery throughput now benefits from it; stability still does not, since AI adoption continues to increase delivery instability according to the report. 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. The code nobody reads today because the queue was too long is the same code somebody who never worked on it will have to change in three years. 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 regulatory deadline in just over two months. The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents to ENISA and the relevant CSIRT, with an early warning within 24 hours. The regulation’s main obligations only apply from 11 December 2027.

The ordering is the crux. The reporting duty comes first, the build requirements later. It therefore lands on codebases whose review depth is demonstrably falling, and it demands an answer within hours to a question that presupposes a functioning approval path: is this vulnerability present in something we shipped. A team that can no longer reconstruct the origin of a change because it was merged unreviewed and without context will not answer that in 24 hours.

What you decide 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. Doubling writing capacity without touching approval capacity buys you more waste, longer waiting times, and a higher incident probability per shipped change.

Three decisions change that, and all three are a matter of days rather than quarters. First, a blocking size limit on pull requests, with a documented exception path. Second, a triage rule that fixes review depth and deadline before a human ever looks. Third, a pickup deadline with a named addressee and visible escalation.

What comes after that is expansion. What comes before it is a queue that keeps growing. If you want to see what those three decisions look like inside an existing delivery pipeline, talk to us.

Sources

• LinearB: 2026 Benchmarks Roundtable, dataset scope
• LinearB: Software Engineering Benchmarks Report
• LinearB, Dev Interrupted: 2026 Benchmarks, AI PR Merge Rate
• Larridin: breakdown of the LinearB figures on the review bottleneck
• Faros AI: AI Engineering Report 2026, full PDF
• Faros AI: takeaways on the AI acceleration whiplash
• Veracode: GenAI Code Security, spring 2026
• Veracode: GenAI Code Security Report, October 2025
• Google DORA: State of AI-assisted Software Development 2025
• METR: randomized study on AI tools with experienced developers, July 2025
• Apiiro: 4x Velocity, 10x Vulnerabilities
• European Commission: Cyber Resilience Act
• EUR-Lex: Regulation (EU) 2024/2847
• The Register: Replit agent deletes SaaStr production database
• Tenable: CVE-2025-54135 and CVE-2025-54136 in Cursor
• securityonline.info: CVE-2025-48757, row-level security in Lovable projects