GitHub Is Capping the AI Pull Request Flood

GitHub has added a setting that lets maintainers cap how many pull requests a person without write access can have open in one repository. Pull requests opened by Copilot or another coding agent count toward the cap. It is a fairly direct response to a problem open-source maintainers have been complaining about for a while: creating a patch has become much faster, but reviewing one has not.

The setting does not impose a GitHub-wide rate limit on AI code. Each repository decides whether to use it and where to set the cap. Trusted contributors can be exempted, and draft pull requests do not count. A person using an agent gets the same allowance as anybody else without write access.

GitHub says developers merged about 25 million pull requests a month in January 2023. The number is now above 90 million. AI did not necessarily cause that entire increase, but it has made volume much easier to create. An AutoGPT maintainer described people keeping five to ten low-quality pull requests open at once. Homebrew had a similar problem with repeated contributions that needed almost identical review, and its maintainer said AI made it worse.

The mismatch is obvious when you look at who does the work. A coding agent can produce a respectable-looking patch in seconds. A maintainer still has to understand the change, decide whether the project even wants it, check the security implications, run or inspect the tests, and think about who will maintain it later.

The person submitting the patch gets most of the speed. The person running the project gets most of the verification bill. On a company team, at least both sides are usually being paid from the same budget. In open source, the reviewer may be giving up an evening so that somebody else can see whether an agent-generated patch gets accepted.

This is already happening outside GitHub's own examples. A CNCF post about Kyverno starts with 20 pull requests arriving in 15 minutes. The author makes the point plainly: generated output can scale almost without limit, while the attention available to review it cannot.

Kubernetes has responded with rules about ownership rather than a ban. Its current guidance for AI-assisted contributions requires the human contributor to test the change, understand it, explain it, and personally handle review comments. If the submitter cannot do that, the pull request can be closed. That seems reasonable. A project needs somebody who can stand behind the code, regardless of how it was typed.

There is a cost to adding friction. New contributors sometimes open rough pull requests while they learn a project, and maintainers do not want to discourage every imperfect first attempt. The useful distinction is between a newcomer working through one change and somebody dropping a stack of generated diffs into the queue. A cap still leaves room for the first person while limiting the second.

GitHub is already planning issue limits and exploring controls for people who spread submissions across many repositories. I expect contribution platforms to add more reputation signals and more ways for maintainers to protect their queues. An open project can welcome outside help without promising unlimited review capacity.

AI can produce a useful patch, and it can produce ten plausible distractions before lunch. GitHub's cap makes the submitter choose which one deserves attention before asking a maintainer to spend theirs.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com