The Human's Scarce Attention

A cohort session got us onto the thing nobody has really solved yet: how do you review a multi-thousand-line AI PR without becoming the bottleneck that grinds everything to a halt? We chewed on smaller PRs, trunk-based development, and letting the tests stand guard, but the bit that stuck with me is that a reviewer staring at a huge diff isn't refusing to read code, they're refusing to reconstruct your intent from scratch.

Had a fun session today in the cohort, and we got onto the topic of reviewing AI-generated code, especially in the context of big submissions, like a full sprint, multiple thousands of lines. How do you deal with that, being the bottleneck and the human in the loop?

Smaller PRs

The first recommendation, of course, is smaller PRs because it’s easier for human eyes to lock on to, and to think about. The problem with that, of course, is the code that’s in one PR likely depends on code that’s in another PR and could easily lead to merge conflicts and rebasing nonsense that kills efficiency.

The answer to that problem is trunk-based development, where you do a lot of smaller things faster, and they get merged into main quicker. This, again, is an organizational construct but if your team is set for rapid-fire PRs then yay! However those PRs might come every 3-5 minutes depending on your task size.

I honestly can’t imagine being the person doing the review, holding up development like this.

The Problem: Reconstructing Intent

I asked Claude what it thought about this problem, and what suggestions it might have. Most of it was kind of useless (smaller PRs doesn’t solve the problem, it makes it worse, and I pointed that out and it said you’re absolutely right!).

Anyway, buried in there was something interesting:

A reviewer staring at a 4,000-line PR isn't actually refusing to review code — they're refusing to reconstruct your intent and risk model from scratch. The diff is the artifact; the reasoning is what they lack. Most of your options below are really about handing them that reasoning so they don't have to rebuild it.
Also worth saying out loud: review of AI-generated code should not be line-by-line style nitpicking — the model already did that, consistently. The human's scarce attention should go to intent, architecture, and risk. Restructure what you're asking them to do accordingly.

You gotta love Claude’s confidence here. “I know how to code, don’t worry about that”. I’ve worked with people like that before…

That said, Claude does know how to code if you give it guardrails, which is the point of #Summer 2026 Cohort. Producing too much code is a good problem to have, don’t you think?

Curious what you think about this. I think if we’re going to use AI to write code for us, we’re going to have to figure out how to trust it more. This might include automated review loops using some plugins out there, or creating your own. Maybe it’s trusting the tests to act as guards.

In the end, we have to balance a human writing code vs. a computer. Which one is better at it?