AI-coauthored pull requests average 10.83 issues apiece against 6.45 for presumed human-only ones, according to CodeRabbit, a code-review vendor whose analysis covered 470 open source pull requests. Teams solved the bottleneck in writing code and built a new one in reviewing it.

68% of engineers surveyed say AI has already changed how they run code review, and 86% of those use AI to pre-screen before a human ever opens the diff, per LeadDev’s 2026 survey. The same survey found review’s own response to all that upstream speed is mixed, not uniformly faster: 29% say reviews now take longer, 24% report time savings, and the largest share, 47%, see no change at all. LeadDev’s own conclusion matches what I’ve been watching: “Manual code review is now the bottleneck.”

The Bottleneck That Moved

I’ve spent years as the person actually opening the diff before I spent years as the person explaining to leadership why the velocity chart didn’t match the delivery chart. Both jobs taught me the same lesson, that whatever stage of a pipeline goes unmeasured becomes the stage that eventually breaks.

Every team I’ve watched adopt AI coding tools ran the same play, and LeadDev’s 2026 survey shows the pattern held at scale, not just for the teams I happened to be watching. 32% of respondents saw their release sizes grow after adopting AI-generated code, against just 5% who saw them shrink, and among the teams that kept a fully manual, human-in-the-loop review on every line, the group you’d expect to feel a volume increase most directly, 38% say they’re now spending more time on review than before. What I watched happen on the teams I was close to, when that added load didn’t get matched with added capacity, was this: review moved faster per PR instead, and defects that used to get caught there started landing in production instead. Headcount and tooling both stayed pointed at the generation stage, because that’s where the visible win was, while review kept running on last year’s assumptions about how much code a person could reasonably read in a day.

More Issues Isn’t the Same Verdict

The 10.83-versus-6.45 gap gets read one way almost everywhere, as proof that AI simply writes worse code. CodeRabbit applied the same issue taxonomy to both cohorts, AI-coauthored and presumed human-only, and found the AI-coauthored pull requests carried higher rates specifically in security, null- and error-handling, and business-logic categories, not just a higher total count. Using one detector on both cohorts rules out the crudest version of instrumentation bias, a tool tuned to catch certain categories simply surfacing more of what it’s good at finding. It doesn’t rule out PR size, language mix, or how each cohort got assembled in the first place, and CodeRabbit’s own report doesn’t normalize for any of those. That’s a real gap in the evidence and it’s the reason I wanted more than one source before leaning on this finding.

What moves me past that skepticism is a separate, peer-reviewed study that used a different dataset and different detectors, with no commercial stake in the outcome, though it shares CodeRabbit’s basic approach of flagging issues through automated analysis rather than tracking real production incidents. Cotroneo, Improta, and Liguori built over 500,000 matched samples, pairing one human implementation against AI-generated versions from three models. Two of those models, DeepSeek-Coder and Qwen-Coder, were prompted directly by the researchers using the same docstring and function signature for each sample. The third, ChatGPT, was inherited from an existing dataset built the same general way but by different researchers, on an older model checkpoint, from the docstring alone, so the three-way comparison is directionally matched, not perfectly controlled. Their results are genuinely mixed, not a clean win for the “AI writes worse code” story: AI-generated code came out simpler and less structurally complex than the human original, and which cohort had more defects overall flipped depending on the language. But on security specifically, the AI-generated code was consistently worse in both Python and Java. OS command injection findings turned up 2,243 times in human-written code versus 7,318 to 13,419 times across the three AI models in Python, and hardcoded-credential findings appeared 784 times in human code versus 901 to 5,199 times across the three models in Java, substantially more common in AI code, not a category humans avoided entirely.

Two studies with different datasets, different detectors, and no shared commercial interest landing on the same conclusion in the same category is stronger evidence than either alone, even though both are counting flagged issues rather than confirmed production defects. It doesn’t prove AI-generated code is worse across the board. The complexity finding cuts the other way, and I’m not reading that as a clean win for AI either: simpler and less structurally complex isn’t automatically better, it can just as easily mean the implementation is doing less, skipping edge cases or error paths that would have shown up as complexity if they’d been handled. What it does give me is real corroboration that the security gap specifically isn’t an artifact of how CodeRabbit counts.

CodeRabbit does flag one real caveat of its own, and it’s about authorship, not scoring. Which pull requests counted as “human-only” was inferred from signals, not confirmed, so that cohort likely includes some undetected AI contribution. That would tend to understate the gap rather than explain it away, but only if the mislabeled PRs are scattered randomly through the human-only cohort. If whatever caused them to evade detection also correlates with fewer issues, the effect could run the other way.

That distinction matters for what a team does next. A team that reads “1.7x more issues” as “our AI tooling is the problem, restrict it” will lose the speed gains it’s actually getting upstream, in generation. A team that reads it as “our review process needs to classify what it’s catching” can fix the thing that’s actually broken. I’d rather know the split among defect, security risk, maintainability issue, style nit, and false positive on my own team’s pull requests than assume either story is the full picture.

Trust as a Line Item

The automated review comments that actually sound like something your team would have said, instead of a generic best-practices lecture, don’t come from context alone or from the fanciest model alone. Recent research on retrieval-augmented review found that grounding comments in a project’s own review history helped larger, code-specialized models the most, while it actually degraded smaller general-purpose models, an effect the authors call context collapse. The best-performing setup in the study didn’t come from context alone either: it combined retrieval with routing each request to whichever model was suited to it, a 13.2% improvement over a zero-shot baseline. Context was necessary for that best-performing configuration, not a universal fix that helps regardless of which model is running it.

That retrieval approach grounds review comments in a project’s own review history, retrieving the most relevant past comments and conventions for a given change instead of generating feedback from generic best practices alone. That’s narrower than full codebase understanding. It won’t tell a reviewer why a decision got made three years ago or surface an architectural invariant nobody wrote a comment about, but paired with the right model, it closes some of the gap between a reviewer that knows how your team has actually phrased this kind of feedback before and one that’s pattern-matching against the internet.

Building that kind of grounding from scratch is a real investment, but it’s no longer the only way to get it. CodeRabbit’s own product now sells exactly this as a feature: codebase intelligence, external context pulled from linked tools, and “Learnings” that store a team’s corrections from chat and apply them to future reviews automatically. The investment didn’t disappear, it moved from building an index to teaching and maintaining one. CodeRabbit’s own documentation recommends a quarterly review of stored learnings and warns that stale or contradictory ones actively confuse future reviews. Skipping that upkeep is a reasonable call given the ongoing cost, but it doesn’t close the relevance gap in automated review by itself, and neither does buying the feature. The retrieval study is a flat reminder of that: the same context helped its strongest models and hurt its weakest ones. Getting real value out of a grounded review tool still means picking a model that actually benefits from that context, not just turning the feature on, and then keeping what you fed it from going stale. Governance and model capability are both live problems here, not one replacing the other, the same way review capacity itself was an unstaffed line item a year earlier.

The trick is finding where the right ratio sits between what a well-grounded, well-matched automated pass should catch and what still needs a human who remembers why a decision got made three years ago. I’m watching my own project’s defect-versus-nitpick split and how much of it lands specifically in the security and business-logic categories for the next few quarters before I’d bet on an answer.