I talked to an open-source maintainer last month who had stopped opening his GitHub notifications. He maintains a mid-sized project, around 3,000 stars, active community, regular release cadence. Healthy by any measure.
In February he received 74 pull requests from AI coding agents. Codex, mostly. A few from other tools. Seventy-four PRs in twenty-eight days, on a project that usually gets twelve to fifteen human contributions per month. Most were small. A renamed variable, a docstring addition, a one-line type annotation fix. Some were genuinely useful. Many were not. About a third failed CI.
The ones that failed CI sat there. Nobody came back to fix them.
He spent the last weekend of February closing thirty-one dead PRs by hand. When I asked him how long it took, he said about two hours. Not because each one was hard to evaluate. Because he felt obligated to actually read each diff before closing it, in case one of them was good.
None of them were.
The scale of the problem
The most extreme example in our dataset is the mochilang/mochi repository, which received 8,151 AI-generated pull requests from Codex alone. Eight thousand PRs on a single project from a single tool.
Most open-source maintainers don't operate at that scale. But the pattern is consistent across the 447 repositories we studied. AI agents are submitting PRs to public repos at rates that dwarf historical human contribution levels. The median repository in our dataset received more AI PRs in Q4 2025 than human PRs.
This isn't inherently bad. Some of those contributions are valuable. But the data shows a structural problem with the ones that aren't.
The 91% abandonment rate
We tracked 7,498 CI failure events across our full dataset of 24,560 pull requests. For every failed PR, we checked whether a subsequent run on the same branch ever passed.
For human contributors, 23.4% of failures get resolved. Someone comes back, reads the error, adjusts the code, pushes again. Nearly a quarter of broken PRs get fixed by the person who submitted them.
For AI-generated PRs, the number is 9.3%.
The agent doesn't come back. It doesn't read CI logs. It doesn't understand the project-specific context that caused the failure. It generated code, submitted a PR, and moved on. The generate-and-submit loop is complete. There is no repair loop.
This means that for every AI PR that fails CI on your project, there is a 91% chance that nobody will ever touch it again. It will sit in your queue, red, sending you notifications, taking up visual space in your PR list, until you manually close it.
What it costs a maintainer
The compute cost is the part people mention first, and honestly it's the part that matters least. Most open-source projects use free GitHub Actions minutes from the open-source tier. When those run out, the pipeline just stops running. Annoying, but bounded.
The real cost is attention.
Every PR that lands in your inbox requires a decision. Is this worth reviewing? Is the change correct? Does it match the project's conventions? Does it introduce a dependency I don't want? Even if the answer to all of those is "close it," arriving at that answer takes time. Reading a diff, even a small one, is not free.
Multiply that by 74 per month and you've added several hours of triage work to a maintainer's plate. This is work that produces no value for the project. It is pure overhead created by a tool that doesn't know and doesn't care whether the maintainer has time to review.
Then there's the PR list itself. Open-source projects use the PR queue as a rough indicator of project health and activity. When half the open PRs are dead bot submissions with red badges, that signal becomes noise. A new contributor looking at the project sees forty open PRs and assumes the maintainer is overwhelmed or unresponsive. The project looks unhealthy when it's actually fine. It just has a pollution problem.
Notification fatigue is the last piece. Maintainers who subscribe to their own repo get pinged on every PR, every CI status change, every review request. A sudden influx of bot PRs turns that notification stream into spam. Some maintainers I've talked to have turned off GitHub notifications entirely in response. Which means they also stop seeing the human contributions that actually need their attention.
What maintainers are doing about it
The simplest defense is a stale-bot configured to auto-close PRs from known bot authors that fail CI and show no activity for 48 hours. GitHub's actions/stale action does this. Set days-before-stale: 2, days-before-close: 1, filter by the ai-generated label or by author patterns. The 91% abandonment rate means this catches almost exclusively dead PRs. False positives are rare because the people who actually fix their AI-generated PRs tend to do it within hours, not days.
Some projects have gone further. A few maintainers I know have added a contributing guideline that requires bot-authored PRs to pass a local lint check before submission, documented in their CONTRIBUTING.md. This doesn't prevent bot submissions, but it gives the maintainer grounds to close PRs that didn't follow the process, without feeling guilty about discouraging contributions.
Branch protection rules help too. Requiring one human approval before CI runs means bot PRs that nobody reviews never consume pipeline minutes at all. This is aggressive and can slow down legitimate contributions, so it's not right for every project. But for maintainers who are drowning in volume, it works.
The uncomfortable reality is that none of these are real fixes. They are defenses against a pattern that will get worse as AI coding tools become more common and more agents get turned loose on public repositories. The tools that generate these PRs have no concept of maintainer capacity, no awareness of project conventions, and no incentive to fix their own failures. They optimize for submission, not for merge.
Until that changes, the cost falls on the maintainer. And the best thing you can do is make sure the cleanup is automated rather than manual.
Based on an empirical study of 24,560 PRs across 447 open-source repositories. I help startups and teams set up CI/CD pipelines, DevOps infrastructure, and development workflows that work with AI tools instead of against them.
Is your CI/CD ready for AI agents?
Most pipelines weren't built for the way AI coding tools work. A quick audit can save you hours of wasted compute every week.