TL;DR:

  • A McKinsey study published earlier this year found code review time increased 12% in teams using AI coding tools, while bug density in unreviewed AI code was 23% higher than human-written code
  • The problem isn’t that AI writes bad code — it’s that it writes plausible code that looks correct on first read but has subtle issues that require more careful review than human code
  • Practical fixes exist: AI-specific review checklists, smaller PR discipline, and automated pre-review checks can recover most of the overhead

Let’s get the good news out of the way first. AI coding tools work. The productivity gains are real — a 46% reduction in time spent on routine coding tasks according to McKinsey’s February 2026 study, and over half of all GitHub commits now AI-assisted. If your team isn’t using them, you’re probably writing code more slowly than you need to. That’s not in dispute.

The problem the same research surfaces — and that engineering leads are starting to talk about openly — is that the code review step is getting harder, not easier. And when review gets harder, two things happen: reviews get slower (the bottleneck shifts from writing to reviewing) or reviews get shallower (which is how you get a 23% higher bug density in AI-assisted codebases where teams didn’t adjust their review process).

Understanding why this happens helps you fix it.

Why AI Code Is Harder to Review

Human-written code has a specific failure mode: it tends to go wrong in ways that make sense given what the developer was trying to do. When you see a bug in a human PR, you can usually trace it back to a misunderstanding or a missed edge case that’s detectable from the surrounding code. The logic of the mistake is legible.

AI-generated code fails differently. It’s syntactically correct, stylistically consistent with the rest of the codebase, and functionally reasonable in the happy path. The issues tend to be subtler: security assumptions that were valid in the training data but not in your specific context, error handling that looks right but silently swallows exceptions, race conditions that only manifest under specific concurrency patterns, or dependencies on version-specific behaviour that the model learned from older code.

A human reviewer seeing a function that looks clean has to work against the grain of their intuition. The code looks fine, so the instinct is to approve. Finding the subtle issue requires the kind of deliberate, line-by-line attention that’s hard to sustain, especially when you’re reviewing a 500-line AI-generated PR on a Thursday afternoon.

There’s also a volume effect. If AI tools let developers write code faster, and if PR size doesn’t change, more code gets submitted for review per unit of time. Code review is roughly linear in the effort required per line — more lines means more review work, regardless of how the code was generated.

Fixing the Review Bottleneck

Keep PRs small. This is the single highest-leverage change. If your developers are using AI tools to write code faster, there’s a temptation to batch that code into larger PRs since each PR still has overhead (context-switching, description writing, waiting for CI). Resist it. A 200-line PR takes a fraction of the cognitive load of a 600-line PR, and the review quality per line is much higher. The goal is not to reduce PR count — it’s to keep each PR reviewable in under 20 minutes.

Write review checklists specific to AI-generated code. Generic review checklists (“does this have tests?”, “is the naming sensible?”) were written for human code patterns. Add an AI-specific layer that covers the most common failure modes:

  • Are error cases explicitly handled, or does the happy path just work?
  • Are there any implicit assumptions about environment, dependency version, or system state?
  • If this function was generated from a description, does the implementation actually match what the description intended?
  • Are any security-sensitive operations (auth, input handling, data access) using patterns verified against your specific stack, not just general best practice?

Use automated pre-review checks. Tools like CodeRabbit, Qodo (formerly CodiumAI), and Sourcery have added specific AI-code review capabilities — they’re not just linters, they’re using LLMs to identify the same class of issues that make human AI-code review harder. Running these as a CI step means the obvious issues are flagged before the human reviewer even opens the PR. That shifts human review attention to higher-level logic and architecture rather than the syntax-level catches.

Change the PR description convention. When a PR is substantially AI-generated, the description should say so and explain what the author reviewed before submitting. “Generated the test suite with Copilot, reviewed each test against the implementation manually, added three tests for edge cases that the AI missed” is a much more useful PR description than “add tests”. It tells the reviewer where to focus and signals that the author took ownership of the generated code.

The Culture Piece

Here’s the thing that doesn’t get said enough: a lot of the review quality problem is a social problem, not a technical one. Reviewing AI-generated code takes more deliberate effort, but developers are under the same time pressure they’ve always been. If the implicit norm in your team is “AI code looks fine, probably fine to approve”, that norm will propagate regardless of what your official review checklist says.

The engineering leads who are handling this well are being explicit about it. They’re saying in team meetings: “Our AI-generated code needs more careful review, not less. The tool writes faster than we used to, which means the bottleneck is now review, not writing. Approving a 600-line AI PR in ten minutes is not a productivity win.”

To be honest, this is the normal pattern for any productivity tool that shifts where in the workflow the work happens. The typing pool didn’t eliminate administrative overhead; it shifted it. AI coding tools haven’t eliminated development work; they’ve shifted it towards review, testing, and specification. Teams that adapt their processes to that shift will capture the productivity gains. Teams that don’t will find the bug density statistics becoming personally relevant.

The fixes aren’t exotic. Smaller PRs, better review checklists, automated pre-checks, and honest culture around what “reviewed” means — these aren’t new ideas. They’re just newly urgent.