David Kravets
June 18, 2026
7 min read
June 18, 2026
7 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
Despite the obituaries for the pull request, it turns out the pull request is alive, loud, and moving faster than the human systems built to review it.
That is the real signal behind GitHub’s announcement to give open source maintainers the ability to set caps on how many concurrent pull requests outside contributors can keep open.
“Maintainers carry the trust layer of open source. As AI makes it easier to generate contributions, we want to give maintainers more choice in how they receive and review that work,” Ashley Wolf, Director of Open Source at GitHub, tells us about today’s new feature. “Pull requests are far from dead. They are evolving from simple code submissions into richer checkpoints for context, review, and accountability, and our job is to make sure maintainers have the controls they need as that evolution accelerates.”
The feature gives repository admins a direct control inside repository settings. Maintainers will be able to set a maximum number of open PRs for users without write access. Once a contributor reaches that limit, another PR waits until one of the existing PRs closes or merges. Trusted contributors can go on a bypass list without receiving full collaborator access.
The feature is simple. The signal is significant. GitHub is giving maintainers a throttle for a contribution system running at AI (slop) speed.
Camilla Moraes, a GitHub Project Project Manager on Maintainer Wins, says the move is to address the problem of “AI Slop at Scale,” and that GitHub has been working with maintainers on a solution to bring them relief.
“Earlier this year, we opened a discussion about a trend that’s been making maintainer’s lives harder: a flood of low-quality contributions that existing tools and workflows weren’t built to handle,” she wrote on GitHub.
In short, GitHub is adding this control because the pull request queue has become a pressure point in the AI era, where cheap code meets scarce human review.
According to GitHub figures shared for this story, site-wide merged pull requests grew from 25 million per month in January 2023 to 90 million per month in March 2026, a 3.6x increase. Commits grew from 389 million per month to 1.4 billion per month, another roughly 3.6x increase. GitHub framed the infrastructure version of this story in April. The company said it began a plan to increase capacity by 10X in October 2025 and, by February 2026, had moved toward a future requiring 30X today’s scale. GitHub tied that shift to agentic development workflows and said repository creation, pull request activity, API usage, automation, and large-repository workloads are all growing quickly.
Image source: GitHub
The social version of the story feels even more immediate. Maintainers feel the heat first.
Wolf described the moment as open source’s “Eternal September.” The company wrote that generative AI makes it easy to produce code, issues, and security reports at scale, and captured the core tension in one clean line. “The cost to create has dropped but the cost to review has not.”
That line, at its core, explains the new PR cap.
GitHub already shipped two foundational PR access controls in February. Maintainers can disable pull requests entirely, or restrict PR creation to collaborators only. GitHub said those settings give maintainers more control over how repositories accept contributions, especially for mirrors, read-only codebases, and projects that want public code without a public contribution queue.
The new PR cap, however, adds a finer, more flexible control. It targets a specific noisy pattern, a small number of users opening many PRs against the same repository in a short period. Moraes describes the cap as “one of the simplest and highest-impact controls” it can ship, because it creates a practical middle ground between fully open PRs and collaborator-only restrictions.
That middle ground matters. Open source thrives on porous boundaries. Maintainers also need quiet rooms, clean queues, and reliable signals.
A cap lets a maintainer say yes to new contributors while protecting the review lane from a flood. A bypass list lets trusted contributors keep moving. The result is a more textured trust model, warm enough for community and firm enough for scale.
Maintainers and contributors have been asking for more PR control for years, even before the AI-coding wave took off.
In a 2021 GitHub Community discussion titled “Request, Ability to turn off Pull Requests,” one user wrote that sometimes maintainers “just want to share code and don’t want the burden of maintaining it, triaging issues or pull requests.” The same request said it would be useful to disable PRs the same way projects can disable issues.
The AI era sharpened that request into something more urgent. In a 2026 GitHub Community discussion about low-quality contributions, one commenter wrote, “Giving repo owners the ability to ‘rate-limit’ PRs from contributors is probably a good idea.” Another comment described the suspicious pattern directly. “You haven’t contributed to this project before and now you are filling 30 PRs” looked unlike normal human contribution behavior.
These examples, and many others, all point to the same bright, uncomfortable truth. Creation is abundant. Review is scarce.
The PR cap sits inside a wider GitHub product push for maintainers.
GitHub’s Maintainer Month “Ships for Maintainers” page lists 40 features and updates built for open source maintainers, including 8 in pull requests, 6 in issues, 4 in notifications, and 3 in moderation.
Several of those changes clearly map to the PR surge.
GitHub moved the global pull requests dashboard into opt-out public preview. The dashboard gives users a unified place to manage PRs, with filters by organization and repository, saved views, inbox sections for drafts and review needs, unread indicators, and status checks visible from the list view.
GitHub added repository member role labels directly to public repository PR lists, including labels such as First-time contributor, Contributor, and Member. GitHub said the change helps maintainers triage PRs faster by showing contributor history at a glance.
GitHub redesigned the PR Files changed page with docked panels so reviewers can keep overview, comments, merge status, and alerts open alongside the diff. The alerts panel surfaces code scanning alerts next to the code review itself.
GitHub also added quick merge-status access inside PRs, giving reviewers a faster way to spot blockers, missing approvals, and readiness signals.
Moderation is getting sharper too. GitHub added a “Low Quality” option to the Hide comment menu across issues, discussions, pull requests, and commits, saying older categories such as spam and abuse failed to capture the growing volume of unhelpful comments.
Notifications are getting cleaner. GitHub added oldest-to-newest sorting so maintainers can work through backlogs methodically, and it improved handling for notifications triggered by spammy repositories and users.
The roadmap keeps going. GitHub says PR archiving is coming soon, giving admins a way to remove low-quality or spammy PRs from the main list while preserving historical context. GitHub also plans issue limits, issue restrictions for collaborators only, more granular interaction limits, and possible global rate limits for users who spray activity across many repositories.
Taken together, these changes form a new maintainer cockpit with more filters, signals, throttles and more calm.
The pull request has always been more than a diff. It is where code meets trust.
AI makes that trust work louder and more demanding. A generated PR can look polished, pass tests, and still miss the project’s architecture, taste, history, and intent. A human maintainer still pays the cognitive cost. Every review carries the soft grind of context switching, the sharp smell of risk, and the quiet burden of ownership.
GitHub’s new caps acknowledge that reality with welcome clarity. The answer to abundant contribution is better flow control. Open source needs invitation, mentorship, and access. It also needs boundaries sturdy enough to protect the people doing the work.
The best version of this future keeps the door open and gives maintainers a handle on the door.
The pull request is alive. GitHub is now giving maintainers the throttle they need to keep it somewhat healthy.
