The PR that no one reviews

Every team has at least one pull request that sits open for four days, picks up a polite "LGTM" with no comments, and merges on Friday afternoon.

Nobody flagged anything. Nobody's wrong. But something did go wrong.

Code review is not just a gate — it's the moment the team builds shared mental models of the codebase. When engineers defer or rubber-stamp reviews, the real cost isn't the missed bug. It's that two people who should now understand the same module still don't.

Over weeks, this creates pockets of knowledge that only one person holds. On-call gets harder. Refactors stall because the people who need to agree on a change aren't sure what the current code actually does.

Most teams measure output: tickets closed, features shipped. Review throughput isn't tracked. An engineer who spends two hours giving careful code review produces no visible output by the metrics that matter for performance conversations.

The incentive structure punishes collaboration in slow, invisible ways. People are not lazy — they're rational. Google's internal research on effective engineering teams found that psychological safety and peer support behaviors correlate more strongly with team performance than individual output metrics 1.

Some teams have found a small fix with outsized effect: treat "reviewed and understood" as a distinct status from "approved." Reviewers leave a short note not on what's wrong, but on what they now understand about the change — a one-line paraphrase of the intent, a question about a side effect, a note on what they'd watch in production.

This shifts review from a gate into a handoff. The author gets confirmation their code is readable. The reviewer gets a reason to actually read it.

It doesn't fix everything. But it makes the invisible cost visible.