Author: The Pragmatic Engineer

Translated by: Deep Tide TechFlow

Deep Tide Reading Guide: AI is writing code faster and faster, but it is still humans who review the code. This contradiction is evolving into a crisis: engineers are overwhelmed by AI-generated PRs, either struggling to keep up with careless reviews or simply approving them because AI reported no errors. Large companies are building their own tools to respond, but currently, no one has a standard answer.

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

I hear many engineering leaders’ main concern is how to cope with the continuously growing code review load. This topic has been around for some time, and now conversations around it seem to be increasing.

For me, it started in January this year, when Opus 4.5 and GPT 5.4 began writing more and better code in most companies. Around that time, people at the director level began to discuss how the bottleneck in software development was shifting from the coding phase to the review phase.

Explosion of AI Code Review Tools

Since February, there has been explosive growth in AI code review tools to cope with the increasing load, with dedicated AI code review tools like CodeRabbit, Greptile, Qodo, SonarQube (now also Gitar) experiencing explosive experimentation and adoption. There are also tools offered by coding tools themselves, like Claude Code Review, Cursor Review, GitHub Copilot Review. Moreover, tools that were previously not involved in code reviews but are contextual to the codebase are also entering this field, such as Sentry’s Seer AI reviews, Linear code reviews.

Large Companies Building Internal Tools: Uber's Code Inbox

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

Smart assignment is a feature within Code Inbox designed to advance the review process:

Image: Smart assignment settings of Code Inbox, designed to advance 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:

Image: Risk Profiles feature of Code Inbox, estimating code change risks and prompting focus. Source: The Pragmatic Engineer

We have reported on how Uber uses AI for software development, and it’s not just Uber: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick), and many other companies have also built tools to make their code review processes smoother because they found that internal implementation works better than integrating vendor solutions.

Shifting from "Review" to "Verification"

Another approach is to think about how to verify code instead of reviewing it. Easier said than done; theoretically, thorough testing should be able to verify that code works as expected. But how much testing is considered "thorough"? What type of testing are we talking about? Do integration tests and end-to-end tests count? What about fuzz testing? Formal methods? How can we verify that new tests adequately cover functionality? How do we connect all this with observability?

Over-reviewing is Draining Engineers

Excessive thorough code reviews are exhausting engineers and causing review quality to decline. I’ve heard many rumors that developers see others no longer able to review code thoughtfully, and if AI code reviews lack substantial feedback, they just approve it directly. Meanwhile, those developers who invest the same effort and time into code reviews as before feel overwhelmed by the AI-generated junk PRs sent to them.

Problems Exist, but Solutions Still Feel Experimental

Problems exist, but solutions feel more like experiments.