Does PR size actually matter?

What open source data can tell us about code reviews and attention spans

Written by Tim Gilboy on

Code review guide

Conventional wisdom says that the larger the pull request the longer it takes to review it.

But is that actually true?

Or, maybe more importantly, when PRs get massive are they still being reviewed as thoroughly as when they’re smaller? (hint, they aren’t)

I took a look at the last year’s worth of pull request data from some of the top 200+ open source projects on GitHub to see what we could glean from how some of the world’s most popular projects write and review their code.

Most PRs are still small

Despite what we’re seeing with LLMs and coding agents like Claude Code generating absolutely massive PRs, the typical PR that I looked at still tended to be very small.

There were almost as many sub 10-line PRs as there were 5k+ line PRs and 46.4% of all PRs were under 100 lines vs only 10.9% of PRs being over 500 lines.

For existing open source projects (and closed source projects for that matter) this makes sense. Most of the changes to an existing codebase are going to be focused on smaller incremental changes, configuration updates, and bug fixes. Massive PRs are much more likely on brand new projects where there is more room to expand and when you’re not nearly as constrained by the existing code.

Now, that’s not to say there aren’t any massive PRs out there in the wild. Across the projects I looked at there were more than 10,000 5k+ line PRs over the past year - although these clustered among just 25% of the repos.

Distribution of Pull Requests by Size

Smaller PRs aren’t reviewed any quicker

Across all of the repos there is almost no correlation between PR size and how quickly a PR was reviewed. If anything, there’s actually a bit of a decrease in median review time for mid sized PRs than for smaller PRS.

Distribution of Pull Requests Review Times

Instead review timing seems to be much more dependent on the project itself.

Across the 233 projects I looked at, nearly every one of them fell into one of three buckets of review distributions:

  1. Bimodal review timings Reviews tend to be completed very quickly (sub 4 hours) or take more than 7 days to complete. These are the majority of all repos I looked at.

  2. Large long tail. Most (25+%) of the reviews take over 7 days and the faster review times are relatively evenly distributed. These are typically for older projects with lots of complexity.

  3. Mostly quick reivews, then a long tail of slow reviews Most reviews (>40% of reviews) take under 1 hour to complete and then there is a long tail of slower reviews. Often seen in projects with large maintainer teams or commercial open source projects.

But that doesn’t really explain why larger PRs take almost the same amount of time to get reviewed as extremely small PRs. There are two potential explanations here:

  1. Large PRs are complex and critical features/improvements and reviewers focus in effort on them.
  2. Large PRs are overwhelming and reviewers can’t review them as thoroughly as smaller PRs.

While both of these are possible, I tend to think the latter is the real driver behind big PRs actually getting merged in faster. There’s just no real way you can review a 10k line PR in as much detail as you can a 250 line PR, so you wind up looking at it at a higher level or drilling in on specific areas/sections and leaving the rest less thoroughly reviewed than you would if it was a series of smaller PRs.

PR volume and size of PRs is going up. What does this mean for reviewers?

I said earlier that most PRs are still small, and that’s true! But we’re starting to see a trend where both the size and number of pull requests is slowly but steadily increasing.

As more developers lean into agentic tools to write code I would just expect this to increase - and potentially increase pretty dramatically. Last week I was talking to a few different teams and every one of them told me they’ve seen a 2-5x increase in the number of commits from their team members.

If that trend holds across the whole industry then the amount of code that needs a review is going to sky rocket and reviewers are going to either have to take a much longer time to complete the average review or the average review is going to have to be less thorough.