A design mistake caught in a pull request costs more than the same mistake caught anywhere before it in the Software Development Lifecycle.
The work already exists. Someone, or something, already spent the effort. Rejecting it means throwing that away, and everyone in the conversation knows it. That pressure is why so many reviews end in a comment thread about naming while the structural problem sails through.
Volume broke the assumption code review was built on
Pull request review evolved around human-scale changes. A person wrote 500 lines in a day, so a reviewer read 500 lines and had a real opinion about them.
Agent-generated changes don't respect that scale. When 2,000 lines or more show up in one request, the reviewer doesn't read them. They skim, spot-check the parts that look risky, and approve. That isn't a discipline failure or a character flaw. It's arithmetic. No amount of insisting that people review more carefully fixes a volume problem. The higher the volume of changes, the less a reviewer can cognitively keep track of what's happening in the changeset.
So the review either has to get smaller or it has to happen earlier. I do both.
Approve the plan before there's code
The cheapest possible moment to reject an essay is while it's still an outline or a paragraph.
Before an agent writes anything substantial, I draft a plan and mark it up in Plannotator, which puts a human gate in front of the work. For example, a drafted plan might just be plain wrong in approach, misses a constraint, or touches a part of the system it has no business touching. Rejecting or revising a plan costs significantly less, because nothing has been built yet. In this situation, nobody is defending sunk effort, including me.
Most of what I catch at that stage would have been genuinely expensive to catch later. A wrong approach doesn't announce itself in a diff. It looks like working code, because it is working code, doing the wrong thing correctly.
Then I review incrementally as the work proceeds rather than in one lump at the end. Same gate, same tool, applied to diffs instead of plans. Small slices, while the context is still live. By the time the change is ready to merge, the review already happened, in pieces, at the moments when changing course was cheap.
Review stopped being a stage and became a rate
That's the shift worth internalizing.
Review used to be a checkpoint you passed through near the end. When generation is slow, a checkpoint is fine, because work arrives at the gate slowly enough for one reviewer to keep up.
When generation is fast, a checkpoint becomes a queue, and queues get processed by lowering standards. The only way out is to raise review throughput, and you raise it by starting earlier and working in smaller pieces, not by asking the reviewer to try harder.
The relief this produced was immediate. Pull request review stopped being the place where all the deferred judgment piled up, because the judgment had already been spent while it was cheap.
One thing to check this week: look at the last five changes your team merged. How many lines were in each, and honestly, were they read? If the answer changes with size, you don't have a review problem. You have a batch size problem.
P.S. - This works on human-written code too. It always did. AI just removed the option of pretending otherwise.