The pull request reviews the wrong thing

A pull request puts the code in focus. The reviewer opens a diff, not the problem the diff is meant to solve. Usually they do not understand that problem well enough to judge whether the change actually solves it, because the business context lives in conversations and tickets they were not part of. So they review what is in front of them: a variable name, a formatting choice, a clever one-liner that could be clearer.

Those things are almost irrelevant in the grand scheme, and the review spends its attention on them while the question that matters goes unasked: does this solve the customer's problem, and was it the right thing to build at all? The tool quietly redirects the most expensive attention in your company, your developers reading each other's work, toward the cheapest possible concerns.

Nobody reads the long ones

It gets worse with size. A ten-line change gets genuine scrutiny. A six-hundred line change gets "LGTM". In my experience the threshold sits a few hundred lines in, after which a review becomes a rubber stamp regardless of how conscientious the reviewer is. The Cisco code review study that most peer-review advice traces back to found the same effect: reviewer effectiveness collapses once a change grows past a few hundred lines.

Put those two observations together and you get the real problem. The trivial changes get bikeshedded to death, and the large, risky ones get waved through, because nobody can hold six hundred lines of unfamiliar change in their head on a Tuesday afternoon. The review is most rigorous exactly where it matters least.

Quality and security do not live in the diff

The strongest objection is that reviews catch bugs and security holes. Take the two separately.

Quality you should automate. Static analysis, type checks, a test suite, the whole thing running in CI on every change. A human re-reading a diff for the things a linter would catch is the same waste I described for QA in the last post: work a machine does faster, more reliably, and without getting bored on the four-hundredth file.

Security is the harder claim, and the diff is worse at it than people think. The baseline, escaping, authentication, the obvious injection surfaces, should be enforced by the framework and by automated checks, not by hoping a reviewer spots a missing call. The security problems that actually hurt you, logic flaws and the issues that emerge from how several systems interact, almost never show up in a single pull request. To catch those you need someone who understands the whole system and takes real time with it, and in a PR queue you get that by accident at best, when a particularly focused senior happens to look closely. Counting on that accident is not a security strategy. The green checkmark mostly buys you the feeling of one.

Review the code while it is being written

The alternative is to make review synchronous: pair, or mob with the whole team. You discuss the approach as you go, decisions get made and explained while everyone is present, and the context lives in the room instead of being reconstructed from a diff three days later by someone guessing at intent. Knowledge is shared as it is created. And because the people working together share the business context, the conversation lands on whether the thing solves the problem, not on tabs versus spaces.

It also fixes the ownership problem from the QA post. With a downstream gate, the author quietly assumes the reviewer will catch anything important, and the reviewer assumes the author thought it through. Working synchronously, the people writing the code own it together, in the moment, with nobody waiting to be blessed.

When the pull request is the right tool

None of this means the pull request is useless. It is the right tool for the job it was built for: open source, where you cannot pair with a drive-by contributor you have never met and the PR is the only interface you have, or a genuinely distributed team spread across timezones where working at the same time is not an option. There the asynchronous review earns its place.

I have argued before that product development is not Open Source development, and this is another spot where that distinction bites. The workflow the open-source world taught us, fork, branch, pull request, review, merge, is a fine default for strangers collaborating across distance and a poor default for a product team that could simply turn on a call. Use it where you must, not by reflex.

Summary

Do not make the asynchronous pull-request review your mechanism for quality, knowledge sharing, or security on a product team. It scrutinises the trivial, rubber-stamps the risky, and hands you a false sense of all three. Automate what a machine can check, do the rest of the review synchronously so it happens while the code and its context are still alive, and keep ownership inside the team. Reserve the PR gate for the case it was actually designed for, strangers contributing across distance.