A pull request is where individual work becomes team work — and where most of the friction in software collaboration lives. A good PR gets reviewed in minutes and merged the same day; a bad one sits for a week, collects drive-by comments, and ships bugs anyway. The difference is mostly about respecting the reviewer’s time, and the AI era has quietly made that harder, because it’s never been easier to produce an enormous diff. This is the second of three on AI-era engineering hygiene, after commits and before code review.
Keep it small — the research is blunt
If you take one thing from this article: small PRs get reviewed; big PRs get rubber-stamped.
A widely-cited finding from code-review research (the classic large-scale study of review effectiveness) is that a reviewer’s ability to find defects stays high up to a few hundred lines of change and then falls off a cliff — somewhere around 400 lines, or past about an hour of continuous review, people stop reading carefully and start skimming. Beyond that threshold, a review is theatre: a green “Approved” on code nobody actually understood.
Small PRs win on every axis: they’re faster to review, actually reviewed rather than skimmed, easier to revert if something breaks, less prone to merge conflicts, and they ship sooner so bugs surface early. The rule of thumb is simple — aim for under ~400 lines and something a reviewer can finish in one sitting. If a change is genuinely large, stack it: a chain of small, dependent PRs, each reviewable on its own, instead of one monster branch.
The AI-era twist: assistants now generate 500-line diffs in seconds, so the temptation to open one giant “here’s the whole feature” PR is stronger than it has ever been. Resist it. The fact that AI wrote a lot of code quickly doesn’t mean a human can review a lot of code quickly — the review bottleneck didn’t move. A huge AI-generated PR isn’t productivity; it’s un-reviewed code wearing a green checkmark. Split the work the same way you would your own.
What a good PR contains
Size is necessary but not sufficient. A PR is a request for a colleague’s attention, so package it well.
- A clear title and description. The title says what, in one line. The body says what changed, why, and how you tested it — link the issue, add screenshots for anything visual, and call out risks and trade-offs. A reviewer who has to reverse-engineer your intent from the diff is a reviewer you’ve already slowed down. Many repos have a PR template; fill it in properly rather than treating it as a formality.
- Small and focused. One concern per PR. If it does three unrelated things, it’s three PRs. This is the same atomic discipline as commits, one level up.
- Self-reviewed first. Read your own diff before you request anyone else’s eyes. You’ll catch the leftover
console.log, the stray TODO, the file you didn’t mean to commit, the commented-out block. Reviewers are a scarce, expensive resource — don’t spend them on things you could have caught yourself. (Reviewing AI-generated code before you even open the PR is part of this — see commits.) - Green CI and tests. Don’t request review on red CI. Let the robots — formatters, linters, type-checkers, the test suite — catch the mechanical problems first, so the human reviewer spends their attention on things machines can’t judge. And include tests for the new behaviour: a PR without them is asking the reviewer to take correctness on faith.
The mindset
Every PR costs a colleague focus and a context-switch. A small, self-reviewed, well-described PR with green CI respects that cost — it gets reviewed quickly, merged sooner, and ships fewer bugs. A giant, unexplained one with failing checks does the opposite: it sits for days, frustrates the reviewer, and lets defects slip through because nobody could hold the whole thing in their head. In the AI era, when generating code is cheap and reviewing it is the bottleneck, the engineer who keeps PRs small and clear is the one who actually ships.
Takeaways
- Small PRs get reviewed; big PRs get rubber-stamped. Research puts the cliff around ~400 lines / ~60 minutes — stay under it, and stack dependent PRs instead of shipping a monster.
- AI makes huge diffs trivial — which makes small-PR discipline more important, not less. A 500-line AI diff is still 500 lines a human has to review.
- Package the PR well: clear description (what/why/how-tested, linked issue, screenshots), one concern, self-reviewed first, green CI with tests.
- Treat every PR as a request for someone’s scarce attention, and make it easy to say yes.
Next: code review best practices in the AI era — how to review well when a machine wrote the code and the CI is already green.
