When engineering teams need a number to justify reviewing AI-generated code, the one they reach for is CodeRabbit's finding that AI-generated pull requests contain roughly 1.7x more issues than human-written ones. It shows up in vendor roundups, in the top results for "review growing volume of AI-generated code," and in internal slides about why review capacity matters. It is also, on inspection, a harder number to use than the headline suggests. Not because it is wrong, but because of what its method can and cannot support. Reading the method matters more than repeating the figure, because the difference between "one vendor measured twice as many issues" and "AI code is known to be twice as buggy" is exactly what decides how a team spends its review budget.
What the report actually measured
CodeRabbit's State of AI vs Human Code Generation Report analyzed 470 open-source GitHub pull requests, 320 labeled AI-co-authored and 150 labeled human-only. Every finding was normalized to issues per 100 PRs, and comparisons used statistical rate ratios. The main result: AI-authored changes produced 10.83 issues per PR against 6.45 for human-only PRs, a roughly 1.7x gap. The largest differences were readability (more than 3x), excessive I/O operations (~8x), and security issues (up to 2.74x). Logic and correctness issues, the category most likely to cause downstream incidents, were 75% more common in AI PRs.
That is a substantial dataset by public-benchmark standards, and the report is upfront about its limits. The authorship question is a real one: the team could not confirm directly how each PR was written, so they inferred AI authorship from commit signals such as Co-authored-by trailers. They state this explicitly, and they add that they cannot guarantee the human-only group actually contained only human work. The floor is honest, which already puts this ahead of the vendor pages that publish a throughput number with no dataset attached. The methodology is published rather than kept inside a sales deck, and that is genuinely rare in this category. It should get credit for that.
There is also a second number doing quiet work in the space. The report opens by citing a separate finding that pull requests per author increased 20% year over year while incidents per pull request increased 23.5%. That pair of numbers does more to explain the review bottleneck than the 1.7x headline, because it shows both sides moving at once: more changes per author, and more incidents per change. Output grew an fifth, and the chance of an incident inside any given change grew faster. That is compounding validation load.
The circularity that matters more than the sample size
The bigger thing to check is who did the measuring. The tool that classified the issues across the 470 PRs is CodeRabbit's own analyzer. A vendor comparing output it labels as "AI" against output it labels as "human," using its own detector, and publishing the result as a market statistic, is a specific situation: the benchmark and the subject of the benchmark are the same company. That does not make the finding fabricated. Readability misses, omitted null checks, and thin exception handling are real failure modes that any reviewer would flag regardless of which tool surfaced them. But it means the 1.7x figure should be quoted as one vendor's measurement, not as a neutral industry baseline.
This is the same distinction that applies across the growing-volume search results. Salesforce's engineering post is a stronger source for the same conclusion because it reports internal signals with concrete numbers and no product to sell: code volume up roughly 30%, pull requests regularly exceeding 20 files and 1,000 lines of change, review latency climbing quarter over quarter, and review time for the largest PRs plateauing or declining, which the team reads as reviewers disengaging rather than as efficiency. DEVOPSdigest fills in the DORA context, noting that lead time, deployment frequency, change failure rate, and MTTR have not improved with increased AI tool use in the 2025 data. Both sources arrive at the same conclusion as CodeRabbit from the opposite direction: the output grew, and validation did not keep up.
The difference between a vendor benchmark and an internal engineering measurement is not always about honesty. It is about what each can establish. A vendor can measure across many repositories but is limited by its own taxonomy and its own detection. An engineering team can measure only its own repositories but knows exactly what its change, its standards, and its failures look like. For a team deciding what to do, the internal number is usually the more actionable one, which is why Salesforce's post, precisely because it is not offering a product, is the page worth citing in an internal writeup about why review needs rethinking.
What the 1.7x number is actually good for
Used correctly, the figure answers the "is this a real problem?" question. If a team is being told AI code is fine because it compiles and passes tests, the report is direct counter-evidence that syntactic correctness is not the same as correctness. The readability and error-handling gaps are the ones worth quoting to an engineering manager, because those are what make agent-written changes expensive to review and risky to merge. A change that looks consistent but violates local naming and structure patterns will not fail CI, but it will burden every future reader of that code. The report's own framing, that humans and AI make the same kinds of mistakes and AI just makes many of them more often and at larger scale, is the honest version of the finding.
What the figure does not tell you is how a given team should respond. 1.7x is an average across 470 open-source PRs. Your codebase, your models, your prompt setup, and your review standards all move that ratio in either direction. A team that feeds its rules and past defects into the review loop should expect fewer idiomatic, readability, and exception-handling misses than a team that gives an agent a bare repository and merges on green CI. The report's own recommended mitigations are mostly about context and structure: policy-as-code, correctness rails, stronger security defaults, and review tooling that has access to the team's patterns. None of those is "review harder." All of them are "give the validator the context it needs."
That last point is where the growing-volume question stops being about generation and becomes about validation. The reason AI review tools exist, Kodus included, is that the human bottleneck is now the expensive one. Salesforce reached the same place internally: whatever the PR generation rate, what determines quality is the review system's context and routing, not how fast the code appears. So the practical reading of the report is not "1.7x, therefore review everything harder." It is "1.7x in the baseline case, and most of that gap is in categories that a well-contexted review process can actually catch." That converts a scary headline into an engineering job: build the routing and context so the human attention that remains lands on the changes where 1.7x is most likely to bite.
The metric you should watch instead
If one number is over-quoted in this space, the alternative worth tracking is review time per largest PR, which is exactly the signal Salesforce says started plateauing. A ceiling there means reviewers stopped engaging with the biggest changes, and that is the failure mode that produces the security and architecture regressions everyone is worried about. Volume claims, whether 30% more code or 1.7x more issues, describe the input. Whether senior reviewers still have attention left is the output that decides if any of it matters. A team watching only its PR count will miss the moment when its most experienced people quietly start approving changes they have not fully read, which the plateau in review time is how that shows up.
The other number worth close reading is CodeRabbit's separate claim about incidents per pull request rising 23.5% while PRs per author rose 20%. If that ratio holds for a team, it means the validation problem is growing faster than the throughput problem, and no amount of faster generation fixes it. That is the reason the growing-volume question keeps being asked: the bottleneck moved downstream, and the cost now sits in review and in incidents, not in how quickly code appears.
