I think the author and many folks here have an unhelpful understanding of code reviews. I suggest code reviews' primary purpose should not be to catch bugs or

I think the author and many folks here have an unhelpful understanding of code reviews. I suggest code reviews' primary purpose should not be to catch bugs or trivial style issues; automated tests and linters exist for those purposes. Instead, code reviews should be primarily thought of as "human comprehensibility tests". When we write code, we've may have spent a significant amount of time thinking about the problem. This puts us in a bad position to gauge how readily someone in the future can reason about our code in order to fix or modify it safely and easily. Code reviews are a mechanism for showing empathy to our future selves, which accumulates over time into a much more pleasant coding environment. Relatedly, comments on a PR are ephemeral. A rule of thumb I use: if a reviewer asks a reasonable question -- something someone in the future might wonder about when I'm no longer around, I answer it by first improving the code.