I Don't Like Code Review. But It's Here to Stay.

There is a growing problem in modern software development that often gets overlooked. The rate at which code is being produced is rising rapidly, and the complexity of existing systems is only increasing. We are getting a ton of new toys and gadgets on the programming side that are, in my opinion, making software development more fun than ever:

• Testing tools, linters, type checking, and memory safety have all seen serious innovation in the 21st century.
• LLMs give new engineers enough context to become effective in hours instead of weeks, and let experienced ones move many times faster when they know what they are doing.
• CI pipelines make it trivial to deploy fully integrated services, so even a basic CRUD app can have a functioning database and load balancer with a single click.

And yet the process of reviewing code has remained relatively stagnant for as long as most of us can remember. Engineers open a pull request, ask someone else to review it, and wait for comments. The reviewer either opens a web UI or checks out the branch locally and reads the diff front-to-back, file A through file Z. Maybe it gets approved. Maybe there is a back-and-forth. Either way, nobody is exactly excited about it.

Even with that human pass, bugs still slip into production. Codebases drift toward worse quality and higher complexity over time. Style guidelines are loosely followed and eventually forgotten. Things get merged that should not have been, if only the right engineer had taken the time to look closely.

But maybe they were on holiday. Maybe they were tired and had not had their coffee yet. Maybe they were frustrated with context switching out of their real work to review a junior engineer's new React component and did not notice the performance implications. And now your dashboard freezes for half a second every time someone moves their mouse across the navbar.

The Point of Code Review

Some people respond to this by asking: why rely on code review to catch those issues at all? Shouldn't you have tests to stop regressions, performance tooling for interactions, and lint rules to keep the codebase consistent?

All of those things help. None of them are sufficient, even with how much better our tooling has become.

• For correctness, the number of behaviors that need to be tested tends to grow exponentially with system complexity. Features interact with other features, edge cases stack up, and requiring exhaustive tests just pushes the impossible burden onto the author.
• For performance, real-world conditions matter. Some regressions only appear under live traffic, real data, and actual user workflows. Exhaustive performance validation is just as unrealistic as exhaustive correctness tests.
• Linters can enforce formatting and obvious rules, but they are weak at capturing the nuanced patterns teams care about most: where data should be fetched, how UI boundaries should be drawn, and what architectural decisions keep a system understandable over time. And even if code "works", quality of the codebase matters for the next ten features built on top of it by other engineers or autonomous agents.

Yet a good code review just might save the day. Some engineer notices an obscure bug in the control flow. Someone spots a `useEffect` that will cause inefficient rerenders. It is not guaranteed, because review is a human process, but the odds improve the more thought and care experienced people put into it.

Reviewing code is still one of the best ways we have to preserve consistent quality and keep regressions down. Trusting your strongest engineers, and giving them the time and space to do that work well, matters.

The Monsters in the Closet

I originally wrote this after reading about the React RCE vulnerability and then looking through the fix .

While most of the conversation was about whether React should have trusted client payloads at all, I was more interested in a different question: how would you have caught this before it shipped? And when you look at the patch, how can you be sure it actually closes the hole?

I cannot answer that confidently at first glance. The code is complicated. The type system is not particularly helpful because of the nature of the problem. There are multiple files involved, and you need to understand how this logic fits into the whole server pipeline.

If you had put me on that review, I would have needed most of a day to truly understand it. And if I were in a rush, I probably would have rubber-stamped it with a quick `LGTM`.

But I bet React's maintainers could have reasoned about it properly. They have seen this class of problem before. They know where the sharp edges are. They know why a `hasOwnProperty` check matters in object deserialization. That is why I do not think it is unreasonable to say this kind of bug could have been caught with better tooling or a better review process than just "read the diff and move on."

The Answer?

Some people hear all of this and conclude that AI should just do all our reviews. I am not convinced.

Could I write up the React bug in a markdown file and ask an AI system to catch similar bugs in the future? Probably. But how useful is that really? The whole point is to catch the novel issues that are not already encoded in the prompts.

AI is clearly valuable for narrow review tasks. It can check patterns, point out suspicious changes, and act like a tireless second pass. But what human review is still uniquely good at is catching the issues that are not documented in tests or markdown files: the subtle problems that resemble things an engineer has seen before, but require system-level reasoning and real-world context to recognize.

That kind of judgment usually belongs to a maintainer who knows the history of the project, understands its tradeoffs, and can tell when something looks wrong even if it technically passes every check. We should appreciate that process, not try to wish it away.

It would be foolish to opt out of a human pass and rely on AI alone, just as it has always been foolish to rely on test coverage alone. Things will slip through. But when knowledgeable people take the time to reason about code, rather than skimming it, the payoff can be enormous.

Conclusion

I have seen a trend recently where code review is treated as more important than ever while the actual process around it gets less and less care. Teams want to automate it away, avoid blocking on it, or reduce it to a perfunctory glance at a text diff.

I cannot help but think that this will come back to bite us.

So yes, I do not like code review. I do not think most engineers do. But it is not going anywhere. So maybe we should dust it off and give it the attention it deserves.