Large code reviews are killing your speed. Learn why small pull requests are essential for trunk-based development.

CodeCraft Diary

Large pull requests are a primary bottleneck in software delivery, undermining trunk-based development principles. The post diagnoses why PRs grow too large — perfectionism, fear of breaking things, horizontal work slicing, and slow review culture — and offers concrete fixes: enforce a 300–400 line PR limit, use feature flags to merge incomplete work safely, slice work vertically for end-to-end value, optimize review turnaround to hours not days, and track PR size and lifetime metrics. The core argument is that small PRs are a discipline, not just a technical practice, and that flow must be prioritized over polish.

Trunk-Based Development: Your Pull Requests Are Still Too Big

When you split the task to smaller peaces it is easier to review this chunk. MVP should be the main target.

My startup has very few developers, about 5, and nobody does code review because the work-mode is “run as fast as you can no matter what”.
I always try to push for smaller PRs and as you wrote, “slicing of work” is a very important art:
Must slice bottom-up; first create a PR for the fundamental changes which must be made, then build on that, and repeat last step.
Some PR’s might end up very large (hundreds of files changes) due to import paths changes, but those type of PRs are acceptable