The Case for Small Pull Requests: Lessons Learned from a Big Mistake

The advice is everywhere: keep pull requests small and focused. Most developers have heard it. Many still submit large ones anyway—usually with good intentions.

I did it once. The experience was instructive.

What Went Wrong#

The task was a sizable feature update. The changes touched multiple parts of the codebase: refactoring, bug fixes, and new functionality bundled together. The reasoning seemed sound at the time—one PR instead of several, cleaner history, less overhead.

When review comments started arriving, it became clear the reasoning was flawed.

Review Overload#

Reviewers had to traverse a large diff with interleaved concerns. Refactoring changes obscured the new logic. Bug fixes overlapped with behavior changes. Each reviewer had to mentally separate what had changed, why, and whether each change was correct—simultaneously.

The result was surface-level feedback. Reviewers found the obvious issues; the structural ones stayed hidden.

Compounding Delays#

Each round of feedback required re-reading large sections of the PR. Every fix I made triggered another full pass from whoever had previously commented. The review cycle stretched far longer than it should have, and the feature sat unmerged while the main branch continued evolving around it.

Why Small PRs Work#

The review problem is not about reviewer effort or attention. It is about information density. A focused PR communicates a single coherent intent. A reviewer can evaluate that intent against the implementation and give precise feedback. There is nothing to untangle.

Reviewability: Reviewers understand the change without studying a large, multi-layered diff. Feedback is specific, not general.

Speed: Small PRs move through the review queue faster. Feedback arrives sooner. Integration happens sooner.

Testability: A narrow change is easier to test. The effects are bounded, the failure modes are predictable.

Reversibility: If something goes wrong, a small PR is easier to revert cleanly without taking unrelated changes with it.

Alignment with Trunk-Based Development#

Trunk-based development relies on small, frequent integrations into the main branch. Large, long-lived branches are incompatible with this model—they accumulate divergence, create merge conflicts, and delay feedback from CI.

Keeping PRs small is what makes trunk-based development work in practice. It is not just a preference; it is a structural requirement for integration velocity.

Conclusion#

The efficiency of a large PR is an illusion. The cost is paid in review quality, cycle time, and integration risk—costs that are harder to see than the upfront effort of splitting work into smaller units.

Smaller PRs require more discipline in how work is decomposed. That discipline produces cleaner commits, clearer code history, and a review process that functions as intended rather than becoming a formality.