Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics of last week's The Pulse issue. Full subscribers received the article below seven days ago. If you’ve been forwarded this email, you can subscribe here.

One thing I am hearing that’s top of mind for many engineering leaders is what is being done to deal with the continuous increase in code review load. It’s been a topic for a while, and more such conversations seem to be taking place.

For me, it began in January, when Opus 4.5 and GPT 5.4 started to write more and better code at most companies. Around then, Director-level folks started talking about the bottleneck of building software moving from coding to the review phase.

There’s been a boom in AI code review tools to deal with the increase in load since February, and an explosion of experimentation with and adoption of dedicated AI code review tools like CodeRabbit, Greptile, Qodo, SonarQube (now also Gitar). There’s also tools offered by coding harnesses themselves like Claude Code review, Cursor review, GitHub Copilot review. And then tools previously not involved in code reviews – but which have context on the codebase – are also adding this, like Sentry’s Seer AI reviews, Linear code reviews.

Larger companies are building in-house tools to improve the code review experience. Uber’s Code Inbox is one case:

Uber’s Code Inbox. From How Uber uses AI for software development

Smart assignments are a feature inside Code Inbox for having reviews progress:

Smart assignment settings for Code Inbox

Then there’s Risk Profiles which estimate the impact of a change, and encourage devs to pay extra attention to risky ones:

Code Inbox tries to estimate the risk of a code change, and bring attention to it

We covered how Uber uses AI for software development, and it’s not just Uber: companies like Cloudflare (AI Code Reviewer), Faire (Fairey), and HubSpot (Sidekick) and many others have also built tools to make their code review flows more fluid, after finding that an in-house implementation worked better than integrating a vendor.

Another approach is thinking about how to verify code, instead of reviewing. This is easier said than done; in theory, thorough testing should be able to verify that code works as expected. But how much testing is ‘thorough’? What type of tests are we talking about? Integration and end-to-end as well? What about fuzz testing? Or formal methods? What about verifying that new tests exercise the functionality as expected? And how do we connect all of this with observability?

Too much thorough code review is burning out engineers, and resulting in sub-par code reviews. I hear a lot anecdotally that devs see others as no longer able to review code with intent, whereby, if the AI code review has no real comments, they just approve it. Meanwhile, those devs who put the same effort and energy into code review as before feel overloaded by AI slop PRs sent their way.

The problems exist, and the solutions feel more like experiments.

What are you seeing inside your company, and how are you dealing with the increase in code reviews? Share your ideas for practical, workable “replacements”?

Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today’s issue covers:

  1. Moving video podcasts off Spotify due to constant reliability issues
  2. “Kimi K3” moment & a US lobby for closed-source AI models
  3. AWS laughs off huge billing error
  4. Industry Pulse

Read the full issue here

Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 software engineering newsletter on Substack.