Don't Do Code Reviews
I code, found, write, and<br>speak.
Veteran CTO who built successful companies through empathic leadership and mastery of software delivery - from sustainable code to stakeholder trust. Now exploring the future of empathic and sustainable tech.
Learn More
Don't Do Code Reviews
First published at Wednesday, 1 July 2026
Don't Do Code Reviews<br>This is a blog article out of a series where I reflect on what I learned during funding, growing (, and selling) SaaS product companies. While I write those things down for myself, since I believe self-reflection helps me learn, I also want to share my thoughts with anybody who might be interested. An overview of all related topics can be found below. I have a bunch of these blog posts lined up, so you also might want to follow me if you like this one.
In the last post I argued that you should not do quality assurance as a separate activity. The same argument applies, almost word for word, to code reviews, and I am even less comfortable making it than the last one. At Qafoo we did not just consult on quality, we built a code review tool. So I have sold the idea, shipped the idea, and I am now telling you to stop using it the way you use it.<br>To be precise about what I mean: I am talking about the asynchronous pull-request review that sits in front of every merge and that most teams now treat as the place where quality, knowledge sharing, and security happen. I am not saying you should never look at each other's code. I am saying that on an internal product team, the PR gate is the wrong tool for almost everything you have made it responsible for.<br>The pull request reviews the wrong thing<br>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.<br>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<br>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.<br>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<br>The strongest objection is that reviews catch bugs and security holes. Take the two separately.<br>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.<br>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<br>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...