I pulled six months of our review history when an exec asked why our defect rate wasn't moving despite "rigorous review." What I found is that almost nothing we call review is finding defects. The approvals cluster in under four minutes for diffs over three hundred lines, which is not reading, it is acknowledging. The comments that do appear are overwhelmingly style, naming, and "could we extract this," none of which is what later pages us. The bugs that actually caused incidents passed review clean, often with two thumbs up, because they lived in behavior the diff didn't make visible: a default that changed, a query that got slower at a data volume nobody had in staging.
So what is the review actually for. Watching the pattern, it is mostly a settlement. The approval is a signature that says "I agreed too," and its real function shows up at the incident review, where "this was reviewed by two people" converts a personal mistake into a process outcome. That is not nothing. Shared liability is a legitimate thing to want. But we are paying senior-engineer hours for it and calling it quality assurance, and the metric we report to leadership is a lie we tell with a straight face.
My claim is that the rubber-stamp and the audit trail are the same artifact, and once you see that, the question changes. If review is mostly social insurance, then most of it should be cheaper and faster, and the actual defect-catching should move to the things that found our real bugs: tests against production-scale data, and a human reading the parts a diff hides. We keep blocking merges to feel careful, while the careful work happens nowhere.
What I have not resolved is whether the theater is load-bearing. Take the audit trail away and I suspect people get more reckless, not less, because the signature was quietly throttling the cowboys. So maybe the inefficiency is the mechanism. I would rather know that than keep pretending the four-minute approval read three hundred lines.