Bugs Per Developer Were Up 9% Last Year, Now 54%: Inside the AI Code Quality Collapse

Most warning signs in engineering stay warning signs. This one moved.

According to Faros AI's 2026 AI Engineering Report, based on two years of telemetry from roughly 22,000 developers across more than 4,000 teams, bugs per developer under high AI adoption rose 9% in the 2025 dataset. Noticeable, absorbable, easy to write off as a transition cost.

In the 2026 dataset, that figure is 54%.

The throughput gains are real and worth stating plainly. Epics completed per developer rose 66%, task throughput rose roughly 34%, and PR merge rate per developer rose 16%. Teams are shipping more than at any earlier point in the dataset.

Then the rest of the system had to absorb it.

What the AI Code Quality Metrics Actually Show

Faros named the pattern Acceleration Whiplash. The full picture separates cleanly into gains and costs:

The Code Churn Number Nobody Quotes

The most revealing figure sits underneath the headlines. Code churn, measured as lines deleted relative to lines added, rose 861%.

Churn means code written and then discarded shortly afterward. Not refactored a year later during a planned migration. Deleted almost immediately.

A meaningful share of the additional output was never durable work. It was motion that had to be undone, and the undoing appears nowhere in the throughput metrics that made the quarter look strong.

Reading the Incident Ratio Precisely

Two findings explain the mechanism, and both are easy to misquote.

Incidents per pull request rose 242.7% relative to the low-adoption baseline. Faros is careful here and so should anyone citing it be: this is a ratio, not a probability. A single PR can be linked to multiple incidents, and not every incident traces to the most recent merge. What the figure establishes is that the relationship between merged code and production failure deteriorated sharply as adoption scaled.

Separately, 31.3% more pull requests merged with no review at all. That is a 31.3% increase in the count of unreviewed merges, not a claim that 31.3% of all pull requests go unreviewed.

Faros is explicit that this is not a story about reviewers becoming careless. It describes review systems overwhelmed by volume they were never sized to handle. That aligns with the supply chain attack we covered in our analysis of review fatigue as an attack surface, where an attacker buried one malicious pull request under 36 decoys and correctly assumed nobody would look closely.

Why Adding Reviewers Will Not Fix a Saturated Delivery Pipeline

The instinctive response is more review capacity. Hire another reviewer, expand QA, invest in faster incident response.

Faros argues this treats the symptom. Our read agrees, for a structural reason worth naming explicitly.

This is Amdahl's Law applied to a software delivery pipeline. Speeding up one component only helps to the degree the rest of the system keeps pace. AI made the writing stage dramatically faster while every downstream stage stayed where it was: review, testing, deployment, observability, incident response.

The bottleneck did not disappear when writing became cheap. It relocated.

The delivery metrics show this directly. Time in progress rose 225.2%, and among organizations instrumenting the metric, commit-to-production lead time rose 480.4%. Code enters the pipeline faster and reaches production slower. That is what saturation looks like from the outside.

Adding a reviewer to a saturated pipeline produces a marginally less saturated pipeline and a burned-out reviewer.

The Measurement Asymmetry That Hid This

There is a reason few teams caught this early.

Throughput metrics are easy to collect and flattering to report. PRs merged, tickets closed, epics completed, deployment frequency. Every one of them rose. A quarterly review built on those numbers looks excellent.

The costs live in metrics most teams do not display alongside the gains: incident rate per unit shipped, review coverage ratio, code churn, and change failure rate. A 66% increase in epics delivered reads as a clear win. Placed beside a tripling of incidents per merge, the same number reads closer to a wash.

Our read: the reporting asymmetry is the real failure. Teams are not concealing the costs deliberately. Their dashboards were designed for an era when output and outcome moved together, and AI severed that relationship without breaking the dashboard.

One caveat worth stating. Faros sells engineering intelligence software and therefore benefits commercially from teams concluding they need better measurement. Weigh that. Also weigh the counterpoint: these findings cut against the prevailing AI productivity narrative, which is not a conclusion a vendor arrives at casually.

Code Review Coverage Metrics and Pipeline Controls That Hold

Four changes, none requiring new tooling budget.

Report Incident Rate Beside Throughput

If a quarterly engineering summary shows epics completed without showing incidents per merge in the same view, the summary is not describing what happened. Pair every throughput metric with its corresponding quality metric in the same table.

Track Review Coverage as a First-Class Metric

Most teams track how many PRs merged. Few track what share received meaningful review. When that ratio falls, the pipeline is saturated, and it will show up there before it shows up in an outage.

A basic version, computed from your Git provider's API:

-- Review coverage ratio, weekly
SELECT
  DATE_TRUNC('week', merged_at) AS week,
  COUNT(*) AS prs_merged,
  COUNT(*) FILTER (WHERE review_count = 0) AS merged_unreviewed,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE review_count > 0) / COUNT(*),
    1
  ) AS review_coverage_pct
FROM pull_requests
WHERE merged_at >= NOW() - INTERVAL '90 days'
GROUP BY week
ORDER BY week;

Track the trend rather than the absolute number. A declining line is the signal.

Enforce Branch Protection Everywhere, Including Internal Repos

Faros found that AI-generated volume finds the exceptions. Internal tooling repositories, where teams typically experiment with AI coding first, are where unreviewed merges accumulate.

Audit every repository rather than the important-looking ones:

# List repos in an org and flag those without required reviews
gh repo list YOUR_ORG --limit 200 --json name --jq '.[].name' | \
while read -r repo; do
  protection=$(gh api "repos/YOUR_ORG/$repo/branches/main/protection" 2>/dev/null)
  if [ -z "$protection" ]; then
    echo "UNPROTECTED: $repo"
  fi
done

Then apply a baseline ruleset:

gh api --method PUT "repos/YOUR_ORG/YOUR_REPO/branches/main/protection" \
  --input - <<'JSON'
{
  "required_status_checks": { "strict": true, "contexts": ["ci/tests"] },
  "enforce_admins": true,
  "required_pull_request_reviews": {
    "required_approving_review_count": 1,
    "dismiss_stale_reviews": true
  },
  "restrictions": null
}
JSON

Constrain Pull Request Size Rather Than Review Time

Average PR size grew 51.3% and files per PR grew 59.7%. Larger changes are harder to review, harder to roll back, and widen the blast radius on failure. Capping change size improves review quality more reliably than asking reviewers to concentrate harder.

A Pipeline Saturation Audit

Work through this in an afternoon:

• Compute review coverage ratio for the last 90 days and chart the trend
• Identify every repository without required reviews on the default branch
• Add incidents per merge to the same dashboard as epics completed
• Measure code churn as deleted-to-added line ratio, month over month
• Check median PR size and flag any repo trending above your review capacity
• Measure commit-to-production lead time, not just deployment frequency
• Confirm rollback is tested and takes minutes rather than a war room
• Ask reviewers directly whether they have time to review properly, and believe the answer

Why Pipeline Work Falls Through the Cracks

The teams we work with at Percime Technologies are rarely short on output. They are shipping plenty. What they cannot do is move it through the pipeline safely.

The fix is usually not another reviewer. It is someone who can rebuild the delivery system to absorb the volume: test strategy that catches regressions without a human reading every diff, deploy gates that fail loudly and roll back cleanly, observability that answers whether users were affected, and CI fast enough that engineers stop routing around it.

This is the argument we made in our earlier editions on DevOps as an operating system, and the Faros data is what that argument looks like measured across 4,000 teams. It also compounds the surface area problem covered in our March analysis: AI added throughput without adding any of the downstream capacity that throughput requires.

The engineers we embed do this specific work in bursts, without becoming permanent headcount. Pipelines, deploy safety, test infrastructure, and the parts of the system that determine whether shipping more actually means delivering more.

AI made your team faster at the one stage that was never the constraint.