The new bottleneck: Code Reviews

The new bottleneck: Code Reviews

It is 2026, and almost every developer I know uses AI to write their code.

Over the last 10 years we more or less solved software development. Code reviews, testing, QA, agile, Kanban, small teams — we knew what good looked like.

All of this was based on humans writing code and reading code at human speed.

This is not the case anymore.

This article is about how AI changes the way we work, and how we should change our habits to match.

Code Reviews

The bottleneck has shifted: from writing code to reviewing it.

This image is a modified version of an image I found here.

The Problem

Code review used to be the gate every change passed through. A developer modified the code, opened a pull request, and one or more colleagues checked that the changes were 'correct', whatever that meant.

Because code was written at human speed, reviews usually kept up. At least in a healthy team.

Nowadays they are the ultimate bottleneck.

Take this PR for example: it adds a whopping 21,774 lines of code, and it triggered a petition that wants to prevent AI code in the Node.js Core.

Now I don't want to go into the PR or the Petition too much, since I don't have the knowledge nor the interest to speculate if this PR is "good" or not. But it shows clearly that reviewing every change before merge does not scale with the speed of AI-generated code.

Speed is not the only problem. The code has different 'defects' than before.

Human code and AI code raise different red flags. In the before-times, a few signs made a reviewer sit up straight, fetch a fresh coffee and really look into the code:

• Spelling mistakes
• Duplicate code
• Vague names
• Incorrect or missing comments
• Missing tests or removed tests

These were the signs that code was probably shit. Nowadays you cannot use these signs anymore. Apiiro measured the inversion:

Defect type	Change
Syntax errors	▼ 76%
Logic bugs	▼ 60%
Architecture / design flaws	▲ 153%
Privilege escalation paths	▲ 322%

In other words: the bugs that were quick to spot in a review mostly disappeared, and the ones that take real time to find got a lot more common.

AI generated code has different issues:

• Much more verbose (AI assisted pull requests are 2.6 times larger than human written ones)
• It over-tests
• It re-implements (sometimes)
• It tends to over-complicate (could write a whole blog post on this alone...)
• It is "mortally terrified of exceptions" (e.g.: loves to handle errors that could never happen at runtime)

So not only do we have more code to review, we have more code that "looks" good but is actually bad. 66% of developers say AI output is "almost right, but not quite".

The Fix

Now that I have over-explained a problem you were already painfully aware of, here is the fix.

Drumroll: there is none.

My first idea was smaller PRs — split each change into manageable chunks.
Does that solve the problem? No.

The volume of generated code is still more than a human can keep up with.
You cannot review code as fast as someone can generate it.

So we choose: either accept that code review is the bottleneck, or stop reviewing code.

This is usually the point where someone mentions AI code reviews. They don't fix it either — the next section covers why.

AI Code Reviews

AI code reviews are great. I use them on every PR I open. The trouble is that they don't find the issues humans find. They find different ones, and sometimes they invent issues or suggest wrong fixes.

And sometimes they just plain old suck, for example Copilot when I last used it (around May 2026):

• It never questions the overall approach. It fixates on details and misses the bigger picture.
• It is nit-picky, flagging 'bugs' that aren't there.

Cursor Bugbot was much better, Claude Code's /code-review is also good. And of course results depend on the model, the context you give it, and so on.

I think AI reviews are useful currently and they could become even more useful but they are not a solution to the bottleneck problem right now.

You still need a human review if you want to keep up quality (and you also need a human to verify that the review is correct).

As described above, the only real way to remove the code-review bottleneck is to stop reviewing.

A strange game. The only winning move is not to play.

— the military supercomputer in the 1983 sci-fi film WarGames

This is already happening btw, just without anyone deciding it: 59% of developers ship AI-generated code they don't fully understand.

To me it isn't a yes-or-no question. It depends on the context.

A small MVP to validate an idea?
Don't review. Validating the idea quickly matters more.

A helper script only developers run?
Don't review. If it breaks, let the AI fix it.

An internal tool three people on your team use?
Don't review. If it breaks, let the AI fix it.

A product you plan to maintain for years?
Review it.

A public API, a shared library, a database migration?
Review it. You can revert a deployment. You cannot revert a schema change or an API contract other teams already depend on.

Infrastructure as code, CI config, feature flags?
Review it. (Especially if you are working at AWS, please)

This take may age badly. It all depends on how much better the models get.

AI Disclosure

I used AI (Claude Opus 5) to fix my embarrassingly numerous spelling and grammar mistakes. I also used Claude Code's /deep-research skill to find sources that confirmed what I already believed, which is something you shouldn't do — but oh well. And most of those sources are companies selling tools for the problem their numbers happen to prove, so take them with a grain of salt.