Most teams that require code review can't explain what it's supposed to catch. Ask, and the answer is usually something like "quality" or "another set of eyes," which is true but not specific enough to tell a reviewer what to actually look for. That vagueness is why review so often turns into either a formality (a quick skim and an approval) or a fight over formatting that has nothing to do with whether the code works.
Review exists to catch what the author can't see
The person who wrote the code has already convinced themselves it's correct. That's not a flaw; it's just how writing anything works. You build a mental model as you go, and by the time you're done, you can only see the code through that model. A reviewer comes in without it. They're reading the actual code, not the intention behind it, which is exactly why they catch things the author doesn't.
The useful question for a reviewer isn't "does this look right?" It's closer to: what happens when the input is empty? What happens if this runs twice? What happens if the network call fails halfway through? An author who was solving the happy path rarely stops to ask those questions on their own, because by definition, they were focused on the case that worked.
Style comments are the easy part, and the least valuable part
Formatting, naming, and structure are worth commenting on, but they're also the parts a linter or a formatter can catch automatically. If most of a team's review comments are about style, that's usually a sign the team hasn't automated the parts that should be automatic, and is spending expensive reviewer attention on the cheapest possible feedback.
The comments that actually change outcomes are the ones about behavior: a missing case, an assumption that doesn't hold under real data, a change that will work in the demo and fail in production. Those require a reviewer to actually run the logic in their head, not just read it.
What makes review work versus what makes it theater
Review works when the reviewer has enough context to disagree with a decision, not just check that the code compiles. That means smaller, focused changes are easier to review well than huge ones. A 40-line change gets read; a 2,000-line change gets approved on trust, because nobody has time to hold that much in their head at once.
It also works better when the author explains their reasoning up front, not just the diff. A short note on why an approach was chosen, and what alternative was rejected, turns review into a conversation about the decision instead of a guessing game about the code.
Review becomes theater the moment it's treated as a checkpoint to clear rather than a chance to find a real problem before a user does. The fix isn't more process. It's making sure the person reviewing actually has room to look for the failure cases, not just the happy path the author already tested.