10 PR/day capacity
Ten PRs per day is the typical throughput ceiling for a manual review-and-merge process on a team of 6-10 developers.
- Pull requests are reviewed before merge
- The team merges pull requests at least weekly
- Basic CD pipeline exists (even if simple or manually triggered)
- Deploy frequency is at least weekly
- PR merge history showing manual approvals
- Deploy logs showing manual trigger or simple CD pipeline
What It Is
Ten PRs per day is the typical throughput ceiling for a manual review-and-merge process on a team of 6-10 developers. It's not a goal - it's a symptom of the bottleneck. When the only way to merge code is for a human to review it, approve it, and click merge, the throughput is bounded by human review bandwidth. At 10 PRs/day, that bandwidth is already nearly saturated for most teams.
This ceiling becomes the central problem the moment a team starts using AI-assisted development. Copilot and Claude Code don't just write code faster - they fundamentally change the ratio of code production to review. A developer who previously opened 3-4 PRs per day might open 8-12 with agent assistance. Across a team of 8 developers, that's a 2-3x increase in PR volume hitting the same human review capacity. The queue grows faster than it can be processed.
The "10 PR/day" number is also a useful diagnostic. Teams below this threshold typically have low AI adoption or high PR granularity issues (PRs that are too large, taking days to review). Teams at exactly this ceiling with growing AI adoption are at the tipping point. Teams that have blown past it and are now seeing PRs wait 48+ hours for review have hit the manual process wall and need to move to L2 automation immediately.
What makes this ceiling insidious is that it's invisible without measurement. Teams don't have a "PR queue depth" dashboard. They experience it as "things feel slower" or "we're not shipping as fast as we should be" without being able to point to a specific number. Measuring PR throughput converts a vague feeling into an actionable metric.
Why It Matters
- AI adoption breaks manual processes - the first measurable sign that AI-assisted development is straining your process is PR throughput hitting the ceiling; tracking this number tells you when you need to upgrade
- Throughput determines delivery cadence - if your team can only merge 10 PRs/day, you can only ship 10 features, fixes, or improvements per day maximum; at L4/L5, this ceiling should be 10x higher
- Queue depth predicts developer frustration - when PRs wait 24+ hours for review, developers context-switch to other tasks, lose momentum, and experience the kind of friction that shows up in attrition surveys
- The ceiling is a planning constraint - sprints that assume faster delivery than 10 PRs/day will fail predictably; knowing the actual ceiling makes planning more accurate
- Measuring it creates urgency - teams that don't track PR throughput often talk about "feeling busy" while actually being constrained; a dashboard that shows "we merged 47 PRs this week and have 31 still waiting" creates organizational urgency for automation investment
Getting Started
- Instrument your merge throughput - add a simple GitHub Actions workflow or use GitHub Insights to track daily PR merge count. Alternatively, use the GitHub API to pull a 30-day history:
gh pr list --state merged --limit 500 --json mergedAt. Plot the trend. - Measure queue depth - track how many open PRs are waiting for review at any given time. A PR older than 8 hours with no review is in queue. A PR older than 24 hours is a signal of process failure.
- Identify your review bottleneck type - is the constraint first-response time (PRs sit unreviewed for hours), iteration time (back-and-forth comments add days), or approval-to-merge time (approved PRs sit unmerged)? Each requires a different fix.
- Calculate your team's sustainable review rate - how many PRs can each reviewer realistically review per day without quality degrading? For most engineers, 3-5 quality reviews per day is the ceiling. Multiply by number of active reviewers. That's your hard ceiling.
- Set a throughput target for next quarter - if you're at 10 PRs/day and adding AI-assisted development, set a target: "We need to be at 25 PRs/day in 60 days." This creates a forcing function for automation investment.
- Triage your current open PR queue - identify all PRs older than 24 hours. Categorize them: waiting for first review, waiting for revision, waiting for re-review, approved but not merged. This categorization tells you exactly where the blockage is.
GitHub's "Time to merge" metric in repository Insights is a rough proxy for queue depth. A rising average time-to-merge with stable PR volume means reviewers are getting slower. A rising average with increasing PR volume means you've hit the throughput ceiling.
Common Pitfalls
Treating PR count as a quality signal. More PRs per day is not inherently better if they're low-quality. The goal is small, well-scoped, independently-mergeable PRs that move fast through review. Large PRs (500+ line diffs) that take a day to review are worse than 5 focused PRs that each take 20 minutes. Before optimizing throughput, optimize PR size.
Increasing reviewer headcount instead of automating. The instinct when the review queue grows is to add reviewers. This delays the problem by 20-30% while increasing coordination overhead. Automation - CI enforcement, policy-based merge rules, linting gates - scales horizontally without adding headcount. Automation is the lever; headcount is a temporary patch.
Measuring PRs opened instead of PRs merged. A high PRs-opened rate with a low PRs-merged rate signals a growing backlog, not good throughput. Always track the merge rate (throughput) not the open rate (input). The ratio between them is your queue pressure indicator.
Ignoring PR granularity. A team that opens 2 PRs per day with 1000-line diffs is worse off than a team that opens 15 PRs per day with 100-line diffs. At L1, teams often have poor PR discipline - features in single large PRs - because there's no tooling to enforce granularity. Start by setting a soft target: no PR over 400 lines of non-generated code.
Not connecting throughput to business outcomes. 10 PRs/day is an engineering metric. Stakeholders care about features shipped, bugs fixed, and release frequency. Build the translation: "our current merge throughput limits us to X feature releases per sprint; to hit the business target, we need Y." This makes the automation investment legible to non-engineers.
How Different Roles See It
Bob's team has been at roughly 10 PRs/day for the last six months. With a new initiative to adopt AI coding tools, the engineering manager has requested headcount to "handle the extra review load." Bob is skeptical but doesn't have data to counter the request.
What Bob should do: Bob should pull the PR throughput data before approving headcount. If the team is at 10 PRs/day and the new AI tools are projected to generate 20-30, adding one reviewer moves the ceiling to 13-14 PRs/day - still insufficient. The data makes the case for automation over headcount. Bob should commission a two-week spike: implement GitHub's native merge queue, add a required CI check, and measure the impact on throughput. A well-implemented merge queue typically increases throughput by 40-60% without adding reviewers, and it costs one sprint of infrastructure work rather than ongoing salary.
Sarah has been building a developer experience survey and one recurring theme is "PRs take too long to get reviewed." She wants to fix this but the engineering team says "we're already reviewing as fast as we can." Both are right - and neither is talking about automation.
What Sarah should do: Sarah should reframe the conversation. She should pull the PR cycle time breakdown: time to first review, time to revision, time to merge. Then she should calculate what fraction of that cycle time is "waiting" versus "active work." For most teams at L1, 70-80% of cycle time is waiting, not working. This reframes the problem: it's not that reviewers aren't fast enough, it's that the process creates waiting states that accumulate into multi-day cycles. The solution isn't faster reviewers - it's removing the waiting states through automation. This shifts the ask from "work harder" to "we need to invest in tooling," which is a more actionable and less demoralizing conversation.
Victor runs 3-5 parallel agents on most days and his personal PR throughput has tripled since adopting that workflow. He's now hitting the review queue as his main constraint: he can produce PRs faster than they get reviewed, so his branches sit waiting, accumulate drift, and require rebase before merge.
What Victor should do: Victor is the best person to make the case for automation because he has concrete, personal data. He should document his weekly throughput (PRs opened) versus the team's review capacity (PRs merged per day) and present the gap. Victor should propose and implement GitHub merge queues for the repositories where he's most productive. He should also advocate for auto-merge on low-risk PR categories (documentation, test additions, dependency updates) with full CI passing, which would clear a significant fraction of his queue without needing human review. This is a 2-3 hour implementation that immediately unblocks his workflow and scales to the whole team.
Further Reading
Where does your team actually sit on this?
This guide describes one level of one area. Run the assessment to place your team across all 16 areas, see which gates you have passed, and get a report you can take to your stakeholders.