AI code generation creates code review bottlenecks as engineers struggle.

Author: The Pragmatic Engineer

Compiled by Deep潮 TechFlow

DeepInsight Summary: AI is writing code faster than ever, but code review is still done by humans. This contradiction is escalating into a crisis: engineers are overwhelmed by AI-generated pull requests, either rushing through reviews carelessly or simply approving them because the AI didn’t flag any errors. Major companies are building their own tools to cope, but no industry-standard solution exists yet.

Hi, I’m Gergely, and this is a free supplement from the Pragmatic Engineer Newsletter. In each issue, I report on large tech companies and startups from the perspective of senior engineers and engineering leaders. Today, we’re covering one of the four topics from the previous issue of The Pulse. Full subscribers received this article a week ago. If this email was forwarded to you, you can subscribe here.

I’ve heard that one of the top concerns among engineering leaders is how to manage the growing burden of code reviews. This topic has been around for a while, but conversations about it seem to be increasing now.

For me, this began in January this year, when Opus 4.5 and GPT 5.4 started generating more and better code for most companies. Around that time, directors began discussing how the bottleneck in software development was shifting from the coding phase to the review phase.

Since February, there has been an explosion in the adoption of AI code review tools to handle increased workloads, with specialized AI code review tools such as CodeRabbit, Greptile, Qodo, and SonarQube (now also Gitar) seeing rapid experimentation and adoption. Additionally, built-in tools from coding platforms themselves, such as Claude Code Review, Cursor Review, and GitHub Copilot Review, have also gained traction. Furthermore, tools previously not involved in code review but with context over codebases are now entering this space, including Sentry’s Seer AI Reviews and Linear Code Reviews.

Large companies are building internal tools to improve the code review experience. Uber’s Code Inbox is one example:

Smart Assignment is a feature within Code Inbox designed to streamline the review process:

Figure: Code Inbox's Smart Assignment settings to streamline the review process. Source: The Pragmatic Engineer

There is also a risk profile feature to assess the impact of changes and encourage developers to pay special attention to high-risk changes:

Figure: Code Inbox’s Risk Profiles feature estimates the risk of code changes and highlights areas of concern. Source: The Pragmatic Engineer

We have reported on how Uber uses AI for software development—and Uber is not alone: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick), and many other companies have built tools to streamline their code review processes, as they found internal implementations to be more effective than integrating third-party solutions.

Another approach is to think about how to verify code rather than review it. Easy to say, hard to do; in theory, thorough testing should be able to verify that the code works as intended. But what counts as “thorough” testing? What types of tests are we talking about? Do they include integration and end-to-end tests? What about fuzz testing? Formal methods? How do we verify that new tests adequately cover the intended functionality? And how do we connect all of this with observability?

Overly thorough code reviews are exhausting engineers and leading to a decline in review quality. I’ve heard numerous reports that developers, seeing others no longer putting in the effort to carefully review code, are simply approving PRs when AI code reviews offer no substantive feedback. Meanwhile, developers who continue to invest the same level of time and care into code reviews feel overwhelmed by the flood of AI-generated, low-quality PRs assigned to them.

The issue exists, but the solution feels more like an experiment.