I made a few claims in the past stating that the average size of pull requests went up by an order of magnitude. I largely based it on hallway conversations with developers at Lunar Logic.

It turns out, the actual data is not that hard to check. Aaaand I was wrong.

AI Effect in PR Size

We pulled data from two very similar projects in terms of complexity, effort, and team size. Both codebases started greenfield and covered a few hundred pull requests in the analyzed period. There was even an overlap across the engineering team. The key difference? How we used AI.

The first project, let’s call it Helpful, happened in the pre-Claude era. While we already used AI to support development, it was predominantly autocomplete with occasional trips to ChatGPT to suggest solutions to pesky problems. All code was managed by developers in real time.

The second gig, I’ll call it Grateful, was full-on Claude. The basic assumption was that none of the code was written by hand. Engineering responsibilities were in context management, prompting, and review.

The bottom line? In an AI-heavy project, average PR size increased by a factor of 3.5.

Yes, I was wrong, but only about the relative scale of the change.

Tiny PRs Have Disappeared

It would be easy to say that AI made us tackle bigger tasks. That’s not what data suggests, though. At least not when we look at the distribution of the PRs.
Note: We sum the added and removed lines to calculate the PR size.

The bulk of PRs in both cases are small to medium ones. A few hundred lines of code tops (our cutoff line was 500). It was the bread and butter of engineering work. It still is.

Sure, in Project Helpful (the “no AI” one), these PRs were skewed toward smaller sizes, while in Project Grateful, the center of gravity was 100-200 lines of code heavier. Still, for an engineer familiar with the codebase, that’s not a challenge.

So, how come the average went up that much?

The answer is on the fringes. The smallest pull requests—the proverbial one-liners—all but disappeared. That’s the single most significant change. Tiny PRs were 1 in 5. Now they are 1 in 20.

The whole class of work items that was easiest to review is at risk of extinction. Let’s park this thought. I’ll be back to it soon.

Large PRs Are on the Rise

What we lost from the tiniest bits of work, we make up for with the largest.

• There are almost 3 times as many large PRs.
• The 90th percentile size increased 3x, from 600 lines of code to 1799 lines of code.
• The outliers inflated even more—the largest PR in Project Grateful was 30k+ lines of code, almost 7 times bigger than its equivalent in Project Helpful.

Big just got bigger. And we get more of it, too.

Still, these chunks of code do not dominate the work. Definitely not just yet. However, there are enough of them to start paying attention.

Coincidentally, this is a class of items that is the most challenging for a reviewer. By now, you can probably guess where it is heading.

The Effects of Processing 3 Times as Many Lines of Code

No matter how I slice the data, it seems that we now deal with tasks that are roughly three times as big as they used to be.

• The average PR size went up from 232 to 817 LoC—a 3.5x increase.
• The median PR size went up from 66 to 210 LoC—a 3.2x increase.
• The percentage of big and large PRs went up from 13% to 33%—a 2.5x increase.

Long story short, our brains process three times as much information per task as they used to. Common sense suggests that the review can’t be as thorough as it was when done in smaller bits.

Research seems to concur. Well-recognized Smart Bear/Cisco study advises keeping pull request size below 200 lines. Above that size, reviewers start overlooking the issues.

“Reviewers are most effective at reviewing small amounts of code. Anything below 200 lines produces a relatively high rate of defects, often several times the average. After that the results trail off considerably; no review larger than 250 lines produced more than 37 defects per 1000 lines of code.”

Executive summary: Heavy use of AI makes individual chunks of work larger, and thus, overall quality drops.

Quality Drop Is Not Inevitable But Highly Likely

If we consider the changes, none of them seems inevitable. I mean, we can tell Claude Code to work in smaller chunks so it’s more convenient to review. Heck, we can make it use the annotation technique advised by the Smart Bear study. As a result, we should sustain most of the quality standards.

There’s only one issue. We won’t do any of these.

It would require engineers to artificially throttle their coding agents. It would mean more back-and-forth between humans and their tools. It would work against our “laziness” instincts.

If an agent handles a big task, why should we split it into smaller ones and review them gradually one by one, again? Isn’t it more effective to have the whole thing run at once rather than stopping it each time it approaches 200 lines of code changes? (By the way, it isn’t, but that’s another discussion.)

Finally, we get the perceived efficiency gains right here, right now, while the cost of lower quality is deferred to the future. Sadly, sticking to the engineering practices that kept the quality high seems highly unlikely.

Glimpse Into the Future

We could ask my favorite question: What does the endgame look like?

• As the capabilities of the models allow them to handle larger and larger coding tasks, the typical pull request size will go up.
• As a result, reviewers will overlook more and more defects.
• The fact that reviewers don’t dive deeply into the code conceptually will only exacerbate the quality issue.
• Thus, we will increasingly develop software riddled with defects.
• Said defects will add rework for coding agents and humans alike.
• The pace of delivery of value-adding items will necessarily slow down, as more effort goes into rework (and rework of rework).

We will go so much faster, only to go as slow as we did in the past. Or slower still. That is, assuming that we stick to the idea of the human reviewer in the loop. And that’s not granted.

For decades, we tried to learn to work in small batches. The hard way, let me add. Now, with AI, we’re making a U-turn as if none of it mattered. I have bad news. It still does. It was never a software-specific thing. In fact, we stole it from manufacturing in the first place.

We will relearn small batches. Sooner than we think.