AI Code Quality Statistics 2026: What the Evidence Shows

Statistics about AI code often travel farther than their methodology. A percentage measured in a benchmark becomes “all production code.” A vendor's internal result becomes an industry baseline. A correlation becomes a cause.

This reference takes the narrower route. It summarizes current primary research, states exactly what was measured, and separates results from implications. Most of the papers are 2026 preprints, so they are useful evidence—not settled law.

1. More than 15% of verified AI-authored commits introduced a detected issue

Debt Behind the AI Boom studied 302,600 verified AI-authored commits across 6,299 GitHub repositories. Static analysis attributed 484,366 issues to those commits. Code smells represented 89.3% of the findings, more than 15% of commits from each of the five assistants introduced at least one detected issue, and 22.7% of tracked issues remained in the repository's latest revision.

What it means: some AI-introduced maintenance issues do survive long enough to become repository debt. What it does not mean: 15% of all AI code is defective. The unit is a commit, attribution relies on verified assistant signatures, and the finding set is bounded by the analyzers and languages used.

2. Removing the agent's abandoned path reduced CodeSlop by 17.9% to 32.9%

The TRIM paper defines CodeSlop as residual, functionally unnecessary edits left by an agent's search process. Its trajectory-minimization method reduced measured CodeSlop by 17.9% to 32.9% across the agent scaffolds studied, with negligible performance regression.

What it means: passing the task is not the same as producing a minimal final patch, and cleanup can remove meaningful residue. What it does not mean: every AI patch is 17.9% to 32.9% waste. The result belongs to the paper's definition, tasks, models, and experimental setup.

3. Open-source review capacity is showing measurable pressure

“AI Slop is DDoSing Open Source” combined practitioner research with an analysis of more than two million pull requests and issues across 294 repositories. The authors estimated that one-time contributors experienced an 18.18% decline in pull-request merge rate relative to the counterfactual, then validated 11 response strategies with 229 open-source practitioners.

What it means: output volume can consume reviewer capacity and change community behavior. What it does not mean: AI caused every rejected contribution, or that the same percentage applies to private teams. This is repository-level observational and counterfactual analysis, not a randomized experiment.

4. Diff-only AI reviewers still miss most benchmark issues

SWE-PRBench evaluated eight automated review systems on a benchmark of 350 real pull requests with human-annotated ground truth. The systems detected roughly 15% to 31% of issues in the diff-only setting, and every evaluated model degraded monotonically as the prompt expanded from the diff to broader repository context.

What it means: an AI reviewer can add a useful pass without being a complete safety net, and simply adding more context can dilute attention instead of improving review. What it does not mean: every product performs exactly like its benchmark configuration in your repository.

5. More comments do not automatically mean better review

CR-Bench was built around a practical problem: code reviewers must balance issue coverage against false positives. A tool that comments everywhere may find more real issues while creating enough noise to reduce trust and increase verification work.

GitHub reported a different kind of evidence after its Code Quality preview: 67.3% of findings in GitHub's own repositories were resolved before merge. That is useful product evidence, but it is a vendor-reported internal result, not an independent cross-company benchmark.

The responsible summary

Current evidence supports four conclusions:

• AI-authored changes can introduce detectable maintenance, correctness, and security issues.
• Some of that residue persists instead of disappearing in later cleanup.
• Higher contribution volume can strain the humans responsible for verification.
• Automated reviewers help, but coverage, context, and false positives remain material constraints.

The evidence does not justify a universal claim that AI code is worse, that a fixed percentage is insecure, or that one tool can replace review. The practical response is layered assurance: keep changes small, test intended behavior, automate repeatable rules, review risky paths with context, and measure what happens in your own repository.

How to use these numbers

Use external research to form a hypothesis, not to invent your ROI. Establish a repository baseline: findings per changed thousand lines, reviewer dismissal rate, escaped defect rate, median review time, and the share of findings fixed before merge. Run a short pilot, inspect false positives, then tighten only the checks that save more work than they create.

If you need a starting workflow, use the complete guide to AI-slop detection. For a measurable deterministic layer, npx --yes aislop@latest scan runs locally; it is one input to the decision, not proof that the code is correct.

Primary sources

• Debt Behind the AI Boom
• TRIM: Reducing AI-Generated CodeSlop
• “AI Slop is DDoSing Open Source”
• SWE-PRBench
• CR-Bench