I've seen a lot of people talking about the practice of code review in a way that I consider unrealistic lately. So here are my thoughts on what code review is—and isn't—for: https://blog.glyph.im/2026/03/what-is-code-review-for.html
What Is Code Review For?

Code review is not for catching bugs.

@glyph @benjamineskola I think a third thing (and the way I use them) is that code reviews are for teaching and steering. Especially on a legacy code base that’s being slowly modernized, I’ll leave tips and hints on ways to improve the code instead of following the old anti-patterns around it. Most of these are non-blocking comments, but a lot of the time, the other devs take the recommendations to heart, make the changes, and then I see them following similar practices on future PRs.
@ramsey @benjamineskola yep, a critical perspective as well, but difficult to fit into a short piece on this. also dovetails with genAI problems too, because due to the current state of most tools I am assuming your code goes in the context window and not the training data. but once we have models that are trained or fine-tuned on your org’s codebase, that is a very specific and more immediate risk of calcification and repetition of historical mistakes

@glyph @benjamineskola Part snark, part honest question:

Does it really matter what the code looks like or how it’s organized when machines are the ones reading and writing the code?

@ramsey @glyph @benjamineskola
if we had AGI it wouldn't matter, but we don't, and LLMs are a dead end towards that goal.

A lot of pro-LLM arguments hinge on what I tend to call "weaponized science fiction", a dangerous trap to fall into.