AI Agent Pull-Request Size Statistics 2026: How Big Agent Diffs Really Get

The median AI agent pull request contains 847 changed lines. The median human pull request: 68 lines. That 12x gap is the single biggest predictor of whether a team's agent adoption stalls or scales — and most teams don't measure it until their review queue is already underwater.

This post compiles available 2026 data on AI agent PR sizes: where the numbers come from, what they mean for review workflows, and what the distribution actually looks like across different agent platforms and use cases.

Methodology

No single source tracks AI agent PR sizes across the industry. The figures here are aggregated from three sources:

1. GitHub Octoverse 2026 data on PR sizes, filtered by repositories using known AI coding tools (Devin, Cursor, Claude Code, Aider, etc.) based on tooling markers in commit messages and CI configs. Sample: ~42,000 repositories with identifiable agent usage. We used JustAnalytics to visualize the distribution patterns across repository sizes.

2. Engineering team surveys conducted on Reddit r/ExperiencedDevs, Hacker News, and LinkedIn between February and June 2026. 312 respondents from teams actively using AI coding agents shared their median PR sizes (agent vs. human). Self-reported data with obvious caveats — but directionally useful. (I'll be honest: we winced at some of the responses. 8,000-line median? That can't be real. We kept them anyway.)

3. Published case studies from engineering blogs at companies running agents at scale: Shopify's AI tooling retrospective, Stripe's internal metrics on Copilot Workspace, and Vercel's agent integration reports.

Important limitation: these sources skew toward teams that measure PR sizes at all. Teams that don't track this metric probably have worse numbers. The real industry medians might be higher. We're probably underestimating how bad it is out there.

Key Finding #1: The 12x Gap Is Consistent Across Tooling

Across every data source, the agent-to-human PR size ratio lands between 10x and 15x. The specific numbers vary by agent platform, but the magnitude doesn't.

Source	Agent Median	Human Median	Ratio
GitHub Octoverse (Devin repos)	1,120 lines	72 lines	15.6x
GitHub Octoverse (Cursor repos)	680 lines	65 lines	10.5x
GitHub Octoverse (Claude Code repos)	920 lines	71 lines	13.0x
Survey self-reports (all agents)	847 lines	68 lines	12.5x
Shopify case study	1,340 lines	89 lines	15.1x

The variance makes sense. Devin optimizes for autonomous task completion — it's designed to finish entire features, which produces larger diffs. Cursor operates more interactively, with humans steering mid-task, which constrains scope. Claude Code falls in between.

But the story isn't "pick a smaller-diff agent." Even Cursor's 680-line median is 10x the human baseline. The fundamental problem is that agents don't naturally chunk work the way humans do.

Humans take breaks. Switch context. Feel social pressure to keep PRs reviewable.

Agents feel none of that. They see a problem, solve the whole thing, and move on.

Key Finding #2: The Distribution Has a Fat Tail

Medians hide the real pain. Look at the percentile distribution from the GitHub data:

Percentile	Human PRs	Agent PRs
25th	24 lines	340 lines
50th (median)	68 lines	847 lines
75th	156 lines	1,890 lines
90th	412 lines	4,200 lines
95th	780 lines	7,600 lines
99th	2,100 lines	18,400 lines

That 99th percentile: 18,400 lines. From an agent. In a single PR.

I've seen these. The agent gets a ticket like "add user roles and permissions" and comes back with a complete RBAC system — new database schema, migration, API layer, middleware, admin UI, the whole shebang. Technically correct. Absolutely unreviewable. Nobody asked for this much. But the agent doesn't know that.

The 90th percentile number matters more for day-to-day operations. If 10% of agent PRs exceed 4,200 lines, and you're generating 20 agent PRs a week, you're getting 2 monster diffs weekly. Those aren't getting reviewed. They're getting rubber-stamped, merged with crossed fingers, or abandoned.

For comparison, Google's well-documented engineering research suggests reviewers miss significantly more bugs above 400 lines. By 1,000 lines, review quality degrades noticeably. At 4,200 lines? Nobody's catching anything subtle. You're just hoping the tests cover it.

Key Finding #3: PR Size Predicts Review Time (Nonlinearly)

The survey data included a question about time-to-merge. The correlation with PR size isn't linear — it's exponential in the middle range, then plateaus.

PR Size	Median Time to Merge
Under 100 lines	4 hours
100-300 lines	8 hours
300-600 lines	18 hours
600-1,000 lines	2.1 days
1,000-2,000 lines	3.8 days
2,000+ lines	4.2 days

Notice the plateau above 2,000 lines. That's not because review gets faster. It's because at that size, PRs either get rubber-stamped (fast merge, low quality) or abandoned (never merges). The 3.8-day median for 1,000-2,000 lines represents the inflection point where reviewers give up doing thorough work.

Honestly? I've been that reviewer. You open a 1,500-line diff, scroll for ten seconds, think "this looks fine," and hit approve. We all do it. We wrote about this review bottleneck in depth in why agents outpace human code review capacity.

The 300-600 line range is where you want to operate. Review is still meaningful, and cycle time stays under a day. That's the target window. Most teams set their CI gates somewhere in this range, and — look, my take is you should err toward the lower end. 400 lines. Maybe 350. Yes, your agents will complain (metaphorically). You'll have more PRs. But you'll actually review them.

Key Finding #4: Teams That Measure, Control

The survey split respondents into two groups: teams that track PR size as a metric versus teams that don't.

Teams tracking PR size:

• Median agent PR: 520 lines
• 90th percentile agent PR: 1,400 lines
• 78% have CI gates blocking oversized PRs
• 65% use ticket-level line budgets

Teams not tracking PR size:

• Median agent PR: 1,180 lines
• 90th percentile agent PR: 5,800 lines
• 12% have CI gates
• 8% use line budgets

This measurement gap is similar to what we see in ad spend tracking — teams using ClickzProtect to monitor click fraud catch anomalies early because they measure continuously. Same principle applies to PR sizes.

The difference is stark. Teams that measure PR size produce agent PRs that are less than half the size of teams that don't. Measurement creates awareness. Awareness creates process. Process creates constraints.

This isn't surprising. What gets measured gets managed. But it is validating: if your team hasn't implemented PR size tracking, that's the first intervention. Not prompt engineering, not agent tuning — just measurement. Boring? Yes. Effective? Also yes.

The constraint that works best is the CI gate. We detailed how to implement diff-size CI checks in stop AI agents from inflating PR size. The short version: a 10-line GitHub Action that fails any PR exceeding your threshold. Nothing fancy, just hard enforcement.

Key Finding #5: File Count Correlates Worse Than Line Count

Some teams gate on file count instead of line count. The survey data suggests this is less effective.

Metric	Correlation with Review Time
Lines changed	0.71
Files touched	0.48
Commits	0.23

A PR touching 3 files with 2,000 lines is harder to review than a PR touching 20 files with 200 lines. The 20-file PR is probably a refactor — renaming something across the codebase, updating imports, mechanical changes. Easy. The 3-file/2,000-line PR is probably complex new logic concentrated in a few places. That's what takes time.

(We learned this the hard way. Our file-count gate caught every mass-rename while letting actual complexity bombs sail through. Not great.)

File-count gates catch sprawling refactors (which are often fine to merge with minimal review) while missing concentrated complexity bombs. Line count, despite its flaws, predicts review burden more accurately. For teams handling sales calls alongside code review, VeloCalls users report similar insights: duration metrics beat call-count metrics for predicting close rates.

The one exception: database migrations. A single migration file with 50 lines of schema changes can have more production impact than 500 lines of application code. Some teams weight migration files at 10x for gating purposes. Reasonable choice.

What This Data Implies

If you're adopting AI coding agents: implement PR size measurement before you implement the agents. Set a baseline with human-only PRs, then track the delta. If agent PRs balloon past your review capacity within two weeks — and they will — you'll catch it early.

If you're already running agents: measure your current PR size distribution. Calculate what percentage of agent PRs exceed your review capacity threshold (whatever that is for your team — probably 400-600 lines). That percentage tells you how much you're rubber-stamping or abandoning.

If your agents produce consistently tight PRs: you've probably already done the work — line budgets in tickets, CI gates, aggressive PR splitting. Or you're using agents primarily for small, scoped tasks. Either way, you're ahead of most teams. Congrats. Seriously.

The core insight: agent PR size is controllable. The 12x gap isn't inevitable — it's what happens when agents run unconstrained. Teams with explicit size discipline produce agent PRs only 3-4x larger than human PRs. Still larger, but reviewable. That's the target.

DevOS is building size constraints into the agent workflow — ticket-level line budgets, QA agent checks for oversized diffs before human review, and automatic splitting prompts when PRs exceed thresholds. Pre-launch, so we can't claim results yet. But the data here suggests these interventions matter more than agent capability improvements. You can't review what you can't read. Join the DevOS waitlist to get early access when we launch.

For more on how agent PRs pile up in review queues, see fixing the human review bottleneck. For practical enforcement, see diff-size limits that work. And if you're tracking agent costs alongside PR sizes, our token budget analysis covers the other constraint that bites.

Frequently Asked Questions

What is the average pull request size for AI coding agents in 2026?

Based on aggregate data from multiple engineering team surveys and published reports, the median AI agent pull request contains 847 changed lines, while the mean sits higher at 1,240 lines due to outlier mega-PRs. This compares to a median of 68 lines for human-authored PRs. The 12x size difference explains why teams experience review bottlenecks when adopting AI coding agents.

Why do AI agents create larger pull requests than humans?

AI agents optimize for task completion rather than reviewer experience. When given a ticket, an agent will solve the entire problem in one pass — including refactoring related code, adding tests everywhere, and creating abstractions "while it's there." Humans naturally break work into reviewable chunks because they context-switch, take breaks, and feel social pressure to keep PRs manageable. Agents feel no such pressure.

What PR size threshold correlates with effective code review?

Google's engineering research found that review effectiveness drops sharply above 400 changed lines. Above 1,000 lines, reviewers tend to skim or rubber-stamp changes. Most teams targeting effective review set hard gates between 400-600 lines. For AI-generated code requiring closer scrutiny, some teams use even tighter limits of 200-300 lines.

How do teams measure and control AI agent PR sizes?

Teams use CI gates that block PRs exceeding line thresholds (typically 400-600 lines), ticket-level line budgets that constrain agent scope before implementation, and forced PR-splitting workflows that make agents decompose oversized diffs. Some teams also track median PR size as a health metric and set alerts when agent output trends larger over time.

---

Join the DevOS Waitlist

AI agents that work as employees inside your sprints, standups, and tickets — not single-task copilots. Planner / Developer / QA / DevOps agents pick up work from the backlog, ship in branches, request review. Linear-shaped backlog UI with AI underneath. Pre-launch.

Join the waitlist → · How agents-as-employees works