There's an inverse relationship between PR size and review quality. A 10-line PR gets read carefully, questioned, improved. A 400-line PR gets a "LGTM" within 30 seconds because nobody has the cognitive budget to actually engage with it.
I used to pride myself on batching work into coherent "complete feature" PRs. The logic made sense: why merge something half-built? The reality was that I was creating review bottlenecks and making each merge a high-stakes event.
The rule I follow now
If a PR takes more than 20 minutes to describe in words, it's too big. That's it. The corollary: if you can't write a two-sentence summary of what changed and why, you probably don't have a clear enough mental model of the change yourself.
How to break it down
The trick is distinguishing preparation from behavior change. Refactors, type changes, moving files, adding tests for existing behavior — these can all land without changing what the app does. Stack those first. Then the actual behavior change is tiny and easy to review.
Your teammates will thank you. Your future self debugging a regression will thank you. The git log becomes a readable history instead of an archaeological dig.