Most teams describe code review as a quality gate: a second pair of eyes catching bugs before they reach production. Measured against that goal it performs modestly, and it introduces the largest single delay in most delivery pipelines.
Measured against what it is actually good at, it is one of the most valuable practices a team has.
Automation catches the mechanical faults
Formatting, unused variables, type errors, common security patterns, and missing tests are all better found by tools: instantly, consistently, and without occupying a colleague.
Every one of those a human finds is a signal that something belongs in the pipeline instead. Reviewers who spend their attention on style have none left for the parts only a person can assess.
What only a person can see
Whether the approach fits the problem. Whether this duplicates something that already exists. Whether the naming will make sense to someone in a year. Whether an edge case was considered. Whether the change belongs in this part of the system at all.
These are design questions, and they are worth far more than the defects a review might catch.
The knowledge transfer is the point
Review is how a team stops having exactly one person who understands each area. That effect compounds quietly and is invisible until someone leaves, at which point its absence is extremely visible.
This argues for reviewing across areas rather than always routing changes to the person who knows that code best.
Small changes get better review
A fifty-line change receives genuine attention. A two-thousand-line change receives approval. Reviewers are not being careless; the ability to hold a change in mind falls off sharply with size.
If reviews are perfunctory, the change size is usually the cause rather than the reviewers.
Separate blocking from optional
Distinguish clearly between what must change and what is a suggestion. Ambiguity here creates long threads about preferences and makes it unclear when a change can proceed.
Where a comment is a matter of taste, say so explicitly. It costs nothing and removes most review friction.
Automate what a machine can judge, and spend human review on the questions machines cannot answer. That reframing usually makes review both faster and more valuable at the same time.