You know the feeling. The pull request is green. The automated checks passed. Three teammates slapped an “LGTM” on it in under two minutes. Your cursor hovers over the “Deploy” button. It should be easy. It isn’t.
Speed doesn’t eliminate risk; it just funnels all the anxiety into the finger hovering over the button.
We’ve been sold a lie about code reviews. We treat them as a quality gate, a frictionless assembly line where more eyes equal fewer bugs. So, we optimize them. We add linters, automated tests, and one-click approvals. We measure turnaround time like it’s a badge of honor. But what are we actually building?
We aren’t building safety. We’re outsourcing context.
The real product of a code review isn’t a bug-free merge; it’s the collective context that makes the push safe.
When you make code review fast and easy, you don’t remove the cost of the change. You just offload it onto the one person responsible for the final push. The reviewer clicks “Approve” because the CI passed. The author moves on to the next ticket. The burden of understanding what the review actually guaranteed falls squarely on the engineer pushing the button.
You’re left holding the bag. You have to decide if the system will survive this change, armed only with a green checkmark and a few thumbs-up emojis from people who probably skimmed the diff on their phones. The faster and easier we make the review process, the more invisible cost we dump onto the pusher.
An automated rubber stamp gives you permission to deploy, but it never gives you certainty.
This is the quiet weight of being the one who must decide. You know the review process gave you permission, not actual proof that the system won’t break. Every engineer and engineering leader is being pulled between speed and safety, but optimizing for throughput at the expense of shared judgment is a trap. If your review process doesn’t force reviewers to hold context, it’s broken. If it doesn’t make people think, it’s just a liability factory.
Don’t build systems that make pushing easier. Build systems that make understanding inevitable.
FAQ
Q: Isn't automation necessary for scale? You can't have deep manual reviews for every PR.
A: Yes, automation is necessary for scale, but it's a tool for syntax, not context. If you automate away the human review, you automate away the shared understanding. Scale the testing, not the rubber-stamping.
Q: What's the practical implication here?
A: Stop measuring code review success by turnaround time. Measure it by how much context the reviewers actually absorbed before hitting approve.
Q: What's the contrarian take?
A: The 'LGTM' culture is actively destroying software quality. It's a liability transfer mechanism disguised as a safety net.