AI Coding Triples PR Size, Cuts Bug Detection

A developer compared two software projects built by overlapping engineering teams over hundreds of pull requests each. The first project, called Helpful, occurred before heavy Claude adoption and relied on autocomplete plus occasional ChatGPT assistance. The second, called Grateful, assumed Claude generated most code, with engineers responsible for context management, prompting, and review. The key finding: average PR size jumped 3.5×, from 232 lines of code to 817 lines.

The increase did not come from larger tasks alone. The distribution tells a more nuanced story. Tiny PRs—single-liners and small fixes—nearly disappeared, falling from 1 in 5 to 1 in 20. The bulk of work remained small to medium (a few hundred lines), but the center of gravity shifted about 100–200 lines heavier in the Claude-heavy project. The real driver of the 3.5× average increase was the emergence of much larger PRs. The 90th percentile jumped from 600 to 1,799 lines, and outliers ballooned: the largest PR in the Claude project exceeded 30,000 lines of code, nearly 7 times the largest in the pre-Claude project. Large and very large PRs, which made up 13% of work in Helpful, now account for 33% in Grateful.

This shift directly impacts code review quality. The author cites the Smart Bear/Cisco research, which found that reviewers are most effective on PRs below 200 lines. Once code exceeds that threshold, defect detection drops sharply. The quote from the study is stark: "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." With the new median PR size at 210 lines and many PRs substantially larger, reviewers will overlook more bugs per task.

The author argues this outcome is not inevitable. Teams could configure Claude to work in smaller chunks, add annotations following best practices, and request gradual review. But he predicts they will not. The incentive structure favors throughput: engineers gain speed and convenience right now, while quality costs are pushed into the future. Splitting AI output into smaller PRs would require more back-and-forth with the tool, running counter to the "laziness instinct" that makes AI attractive. Faced with the choice of running a large task once or stopping the agent every 200 lines to review incrementally, teams will choose the former, even though the latter would maintain quality.

The author sketches an endgame: as AI models handle larger tasks, PR sizes grow further, reviewers catch fewer defects, and conceptual understanding of code degrades. Bugs accumulate, forcing rework on both humans and agents. The initial speed gain erodes as teams spend more effort fixing defects and rework of rework. Delivery slows back to historical pace—or slower. The author notes this mirrors a hard-won lesson from manufacturing and software: small-batch work prevents defects and waste. For decades, teams learned to work in small batches. Now, with AI, he observes, the industry is making a U-turn as though that lesson never happened. His conclusion: teams will eventually relearn small batches, probably sooner than expected, once the cost of technical debt becomes undeniable.

The article compares two greenfield projects of similar complexity and team overlap, differing only in how AI was used. Project Helpful relied on autocomplete and occasional ChatGPT queries, while Project Grateful assumed Claude wrote most code with engineers handling context, prompting, and review. This natural experiment revealed a structural shift in work patterns rather than simply larger tasks: tiny PRs (1-liners) dropped from 1 in 5 to 1 in 20, while large PRs roughly tripled. The author initially believed the change was order-of-magnitude larger based on hallway conversations, but the data showed a 3.5× increase—large enough to matter, but not as extreme as anecdotal evidence suggested.

The significance hinges on a specific research finding: the Smart Bear/Cisco study shows reviewers catch substantially more bugs in code below 200 lines, with defect detection dropping sharply above that threshold. The new median PR size sits exactly at 210 lines, and the distribution now includes many more very large PRs (up to 30,000+ lines). Because reviewers process three times as much code per task, the author argues quality degradation is highly likely—yet the economic incentive structure (immediate speed, deferred cost) makes it unlikely teams will voluntarily constrain their AI agents to maintain smaller PR sizes, even though doing so would preserve review quality.