"Our review bandwidth cannot keep up. While AI dramatically increased code generation volume, human review capacity hasn't expanded at all"—this concern has surfaced frequently among teams embedding AI agents into engineering workflows. AI has multiplied coding speed, yet the bandwidth of human reviewers verifying correctness and evaluating merges remains fixed. Widening the production tap while keeping the inspection valve unchanged clogs pull request queues and erodes thorough quality checks.
In open source communities, this bottleneck emerged even more acutely. In June 2026, GitHub introduced a capability allowing repositories to cap the number of pull requests opened simultaneously by contributors without write access. Driving this change is the flood of mixed-quality AI-generated PRs overwhelming maintainers. This feature provides a valuable case study for safeguarding review bandwidth within custom development teams.
Why PR Limits Became Necessary
Monthly merged pull requests on GitHub exceed 90 million, with growth fueled partly by AI tool proliferation. The core issue is less the gross volume than the steep cognitive tax placed on maintainers to distinguish genuine contributions from casual AI noise. For open source maintainers relying on volunteer labor, evaluating a barrage of unvetted PRs was pushing capacity to the brink.
GitHub's PR limiting feature is designed specifically to protect reviewer bandwidth through the following controls:
- Imposes limits on concurrent open PRs from contributors without write access, blocking new submissions once reached until existing PRs are closed or merged
- Includes PRs generated by AI agents like Copilot within the concurrency count
- Excludes draft PRs from counting against the threshold
- Permits trusted contributors to be added to a bypass list, lifting limits without granting broad repository write access
Crucially, this mechanism does not ban AI outright. Rather than shutting out AI contributions categorically, it throttles incoming volume to match maintainer processing capacity.
What This Reveals for Custom Development
This challenge is not unique to open source. In custom development, where internal engineers and AI agents produce high volumes of PRs, the fundamental dynamics are identical. The difference is that reviewer bandwidth is consumed not by external submissions, but by code generated within your own team.
Here, the solution is less about throttling raw PR counts than architecting workflows so that PRs are only submitted once they are genuinely ready for human review. GitHub's decision to exempt draft PRs offers a clear blueprint, establishing a boundary between exploratory work and submissions demanding human judgment. Letting AI draft code freely is fine. However, claiming human review time should be restricted to work authors have read through and endorse with confidence—enforcing this standard programmatically makes all the difference.
| Practices Straining Review Bandwidth | Architecture Protecting Bandwidth |
|---|---|
| Forwarding raw AI output directly to reviewers as PRs | Authors conducting a full read-through and self-review before requesting feedback |
| All PRs queuing indiscriminately for review | Separating drafts from formal reviews, admitting only complete submissions |
| Uncapped PR accumulation across all contributors | Differentiating submission paths based on author trust and track record |
Who Owns Accountability for "Faster Thanks to AI"?
Another vital consideration for custom development is determining who assumes responsibility for reviewing and merging AI-generated code. When a PR arrives with the caveat, "AI wrote this so I don't fully understand it," reviewers are forced to parse unfamiliar code from scratch, escalating cognitive load. Speed gains from AI generation are immediately negated by inspection delays.
For this reason, AI-generated PRs must carry a prerequisite: the submitting engineer must understand the code and be prepared to explain it. This is an operational and cultural requirement rather than a purely technical one. The balance between automated generation and human responsibility connects directly to our discussion in who bears responsibility when AI automates development, and realistic productivity assumptions are detailed in our review of custom development realities in 2026.
When consulted on resolving review bottlenecks, our team introduced a draft-review separation alongside a requirement: "Every formal review request must include a single line explaining the intent of the change and what was verified." Raw AI dumps cannot fulfill this requirement. Ineligible submissions cannot enter the review queue, naturally reserving reviewer attention for finished work. Tooling limits serve as valuable reinforcement for this process design.
Start by Inspecting the Review Queue
Open your team's pull request dashboard and evaluate how many pending reviews have accumulated, noting how many were submitted without the author fully grasping the underlying implementation. Tactics to accelerate production are plentiful; the next priority is engineering your review workflow so humans can comfortably validate that output. Viewing GitHub's PR limits as institutional validation of this necessity offers practical inspiration for your team's development lifecycle.
Source: How pull request limits are cutting down the noise (The GitHub Blog) / Limit open pull requests for users without write access (GitHub Changelog)
