AI-co-authored pull requests carry 1.7 times more issues than human-written ones, according to a December 2025 study that reviewed 470 real GitHub pull requests. That's not a guess about AI code quality in the abstract, it's a measured gap in a real, disclosed dataset, and it lines up with three other independent reports pointing at the same underlying problem: code generation has scaled faster than AI code review practice has kept up with.

The real gap: what a 470-PR study found

CodeRabbit's "State of AI vs Human Code Generation" report, published in December 2025, analyzed 470 open-source GitHub pull requests: 320 AI-co-authored and 150 human-only, using the company's own structured issue taxonomy to tag findings in each. The topline number: AI-co-authored PRs averaged 10.83 issues per PR against 6.45 for human-only PRs, a 1.7x gap. At the 90th percentile, the worst 10% of PRs in each group, that gap widened to 2.11x: 26 issues versus 12.3.

The category breakdown is where the study earns its usefulness. The gap isn't spread evenly across every kind of issue, it concentrates hard in a few places. Logic and correctness findings ran 75% higher in AI-co-authored PRs, readability findings were 3x higher, and security findings ran up to 2.74x higher.

Error-handling gaps came in at nearly 2x, formatting issues at 2.66x, and naming inconsistencies at close to 2x. Across severity tiers, AI-co-authored PRs showed 1.4 to 1.7x more critical and major findings.

One limitation worth stating plainly, since the study does: authorship wasn't confirmed for every PR at scale, researchers inferred AI co-authorship from available signals and treated unmarked PRs as human-written. That's a real, disclosed methodological constraint, and it means the true gap could run in either direction from what's reported. The Register's coverage and CodeRabbit's own release both disclose it upfront.

What's actually degrading in the codebase

A separate report shifts the lens from individual PR quality to what's happening to the codebase over time. GitClear's "The Maintainability Gap" analyzed 623 million code changes from 2023 through 2026 and found block duplication up 81% over that window, reaching what the report calls the highest level on record.

The more telling number sits underneath that one. Moved or refactored code fell from 21% of changed lines in 2022 to 3.8% in 2026, while copy-pasted code rose from 9.4% to 15.7% over the same stretch. Developers are now roughly five times more likely to copy-paste a block than to refactor it into something reusable.

Two-week code churn is up 15%. Long-term maintenance of existing code, the kind of update that touches something written months or years earlier, dropped 74%, from 1.7% of changes in 2023 to 0.46% in 2026. Cross-file function calls are down 35% since 2023, and error-masking constructs, broad catch blocks that swallow exceptions rather than handle them, are up 47%.

Put together, this isn't a story about AI writing obviously broken code. It's a story about a codebase quietly losing the properties that make it maintainable: less reuse, less refactoring, more duplication, more code that silently hides its own failures.

The error-masking number deserves a beat of its own. A 47% rise in broad catch blocks means more places in the codebase where a real failure gets swallowed instead of surfaced, the program keeps running, the log stays quiet, and the bug shows up later somewhere harder to trace back to its source. Combined with cross-file function calls down 35%, the pattern is consistent: code that's easier to generate in isolation and harder to actually trace through when something goes wrong.

Review isn't keeping pace with generation

The clearest evidence that review hasn't scaled with generation comes from GitHub itself. Octoverse 2025 reports that Copilot's coding agent alone authored more than 1 million pull requests between May and September 2025, five months. Over roughly that same period, comments on commits fell 27% year-over-year, even as overall commit volume rose. Comments on issues and pull requests stayed essentially flat, up 0.35%.

GitHub is careful about what that means, calling it "an observational signal rather than a causal claim," and that caution is worth keeping. The drop in commit comments doesn't prove reviewers are rubber-stamping AI output. But it's consistent with a review process built around a certain volume and shape of code suddenly facing a lot more code, generated faster, in a different shape, without a matching increase in review attention. GitHub's own data on the other side of the ledger: 72.6% of developers using Copilot's code review feature said it improved their effectiveness, so the response to more AI-generated code being AI-assisted review isn't failing, it's just not obviously winning the volume race yet.

The productivity-quality tension isn't hypothetical

Google's 2025 DORA report puts a number on the upside that makes all of this worth taking seriously rather than dismissing: over 80% of developers report a real productivity gain from AI, and 59% report a positive effect on code quality. AI adoption is linked to higher software delivery throughput in the report's own words.

Then the report states the other half directly, without softening it: "the ongoing challenge remains of ensuring software works as intended before it's delivered to users." That's not a contradiction of the productivity numbers, it's the same finding from a different angle. Teams are shipping more, faster, and the part of the pipeline that used to catch problems before they shipped hasn't been rebuilt to match.

What actually changes in how you review AI-generated code

The category-level data points to a specific, practical adjustment rather than a vague "review more carefully." If logic and security findings carry the widest gap between AI-co-authored and human-only code, that's where limited review attention should go first; formatting and naming carry a real gap too, just a lower-stakes one.

Picture a two-person team merging a dozen AI-assisted PRs a week. Spending equal review time across every PR, styled the same way it was before AI wrote any of the code, means the categories with the biggest real gap (logic errors, security findings) get the same scrutiny as the categories with the smallest one (formatting). Weighting review time toward what the data says actually breaks more often is a better use of the same hours, not more hours.

The GitClear numbers point to a second adjustment: watch for copy-paste standing in for refactoring. A pull request that duplicates an existing block instead of extending it isn't just a style nitpick, it's the specific pattern the data says is now nearly five times more common than it was four years ago, and it compounds. Catching it in review is cheaper than fixing it after it's spread through a codebase.

The GitHub numbers point to a third: "it compiles and looks clean" was never a reliable proxy for correct, and it's a weaker one now than it was before. Code that looks clean is exactly what a study built around a structured issue taxonomy was designed to catch past, since a human skim doesn't apply that same taxonomy by default.

None of this argues for reviewing every AI-generated line by hand at the same pace a human would write it, that would erase the real productivity gain the DORA numbers show on the other side of the ledger. It argues for spending review attention unevenly, on purpose, in the direction the actual data points: a targeted second pass on logic and security in a PR an agent wrote, a quick scan for copy-pasted blocks that should have been a function call instead, and a test suite that actually runs the error-handling paths a broad catch block might be quietly swallowing.

Quick reference

The actual verdict

None of this data says AI-generated code is unusable, the same reports that measure the gap also measure a real productivity gain on the other side of the ledger. What it says is narrower and more useful: the gap is real, it's measurable, it concentrates in specific categories, and most teams' review processes haven't been rebuilt to account for any of that. Where AI coding agents reliably break covers the failure modes that show up once an agent is running unsupervised; this is the failure mode that shows up even when a human is nominally still reviewing every line, because the review itself wasn't built for what's now coming through it.

Is vibe coding bad? already made the case that the risk isn't AI-generated code itself, it's AI-generated code nobody actually reviews. This data adds the specifics: which categories to watch, and by how much the odds shift. From code writer to orchestrator describes the same shift from a different direction, a senior engineer's job increasingly means reviewing what an agent wrote rather than writing it themselves, and reviewing it well now means knowing where that code is statistically more likely to be wrong.