Code review is the last gate between an engineer's intent and production.
The premise is sensible: a second pair of eyes reduces risk. Require approval before merge. Force the team to think twice. Catch what the author missed.
In practice, the pull request has become a toll booth. The code passes through not because it was inspected, but because someone clicked a button.
⸻
The Approval Theatre
A pull request sits in a queue. The reviewer has their own sprint work. They have three other reviews waiting. They open the diff, scroll through 400 lines of changes, and scan for obvious disasters.
They do not understand the full context. They were not in the design discussion. They do not know why this particular approach was chosen over the alternative. They look for syntax, not semantics.
The review takes four minutes. The approval is granted. The system records this as quality assurance. It was not. It was a timestamp.
⸻
The Bottleneck Inversion
When every change requires review, the review queue becomes the throughput constraint. The team's velocity is no longer determined by how fast they can write code. It is determined by how fast someone else can read it.
This creates a perverse dynamic. Engineers batch their changes into larger pull requests to reduce the number of reviews needed. Larger pull requests are harder to review meaningfully. The reviewer, overwhelmed, approves faster with less scrutiny.
The process designed to slow down mistakes has created an incentive to make bigger ones.
⸻
The Knowledge Asymmetry
The author of the code spent hours, sometimes days, building the mental model required to write it. The reviewer has minutes.
No review process can close this gap. The reviewer is structurally disadvantaged. They are making judgments about a system they have less context on than the person who built it.
When the reviewer does push back, the cost is high. It triggers a conversation. The conversation requires synchronous time. The change request goes back to the queue. The cycle restarts.
⸻
The Honest Fix
Code review has value. But only when the reviewer has context.
Pair on the design before the code is written. Make the review a confirmation, not a discovery. If the reviewer is surprised by the approach, the process already failed, upstream of the pull request.
Stop measuring quality by approval counts. Measure it by how often the reviewer had to ask "Why?"
End.