GlyphI'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
Ben Ramsey@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 @benjamineskola serious answer I guess: “machines” is too vague a term. but while LLMs may do things that could be described as “reading” or “writing” code, it’s unambiguous that humans are the only ones *understanding* the code. Hal Abelson famously observed in the first edition of SICP, “Programs must be written for people to read, and only incidentally for machines to execute.” That’s still true today.