Writing

The end of line-by-line human PR review

The era of line-by-line human pull request review is ending. For years, the review process assumed that a person would read every diff, check for style problems, spot edge cases, and reason about whether the change made sense in the wider system. That model still works when a team produces a modest amount of code and most changes are small and deliberate. It does not scale when AI-assisted development produces more code than any reviewer can absorb in a single day. The bottleneck moves from writing code to reading it, and that is a losing position for a human reviewer.

What replaces the old review is a tighter contract. We stop asking reviewers to read every implementation detail. We ask them to define what correct looks like before the code exists. Instead of reacting to a diff after it is written, the team agrees on constraints and expectations up front. That contract is made of four parts:

• Pre-code rules
• Automated guardrails
• Multi-model review bots
• User acceptance testing

Each of these parts moves verification earlier or automates a piece of what a human reviewer used to do by hand. Pre-code rules prevent known unsafe patterns from ever reaching a PR. Automated guardrails catch mechanical issues at the moment of the change, without waiting for a person to notice. Multi-model review bots can compare different interpretations of the same diff and surface disagreement cheaply, which is useful because one model may miss what another catches. User acceptance testing adds the final check that the result matches what the user actually needed, not just what the spec says. None of these replace human judgement; they relocate it from reading code to designing how the code is checked.

Review the contract, not the code.

But this is not a free pass. Lean too hard on automation without a human sanity check for business logic, and you will ship plausible-looking wrong code. The counterexample is an over-reliance on tests that pass but miss intent. A test can be green while the system does the wrong thing for the wrong reason, because the test itself was written against an incorrect assumption. Automated guardrails can reject the wrong patterns and still miss the one that matters. Review bots can agree with each other and be wrong together. The human sanity check is not about reading every line; it is about verifying that the contract itself encodes the business intent, not just a plausible story about it. A human still needs to ask whether the rules and tests reflect what the user actually wants.

The skill shifts from reading code to designing verification. A great reviewer used to be someone who could hold a lot of context in their head and spot subtle defects in a diff. The equivalent skill now is building systems that catch defects before a human ever looks, and deciding where human attention is still worth spending. It is less like proofreading and more like designing an experiment. You specify the hypothesis, set up the conditions, and interpret the result. That is a different kind of rigor, and it is the one most teams will need.

Quality isn't inspected in. It's designed in. That has been true in manufacturing for decades. Software is finally reaching the same point with review. The question is not how fast we can read AI-generated code. The question is how well we can define what good looks like before the code arrives.

Originally covered at scienceisneato.substack.com ↗