Are AI-Generated PRs Killing Open Source?

How projects can use AI contributions without drowning in noise

When Mitchell Hashimoto, Ghostty’s creator, released a system called “Vouch,” the point was not a better code-review tool. It was an admission about where maintainer hours now go: AI tools make plausible-looking contributions trivially cheap to produce, and unreviewable submissions compete with real fixes for the scarcest resource in open source, which is a trusted human’s attention. The first months of 2026 show what happens when nothing absorbs that load. One Python maintenance collective shut itself down, and curl killed its bug bounty after AI slop pushed the valid-report rate below one in twenty.

The Deluge Is Here

Open source maintainers have always dealt with drive-by contributions. But 2024 and 2025 brought something unprecedented: waves of pull requests generated entirely by AI tools, submitted by developers who often didn’t even read the code they were proposing. The pattern became familiar:

A user runs an agent against an open source repository
The agent generates “fixes” for issues, often hallucinated problems or cosmetic changes
The user submits PRs en masse to dozens of repositories
Maintainers burn hours evaluating code that should never have been submitted, crowding out genuine contributions

The New Stack’s April 2026 report on the crisis describes the arrivals plainly: verbose changes with nonsensical descriptions, and contributions that submitters cannot explain when questioned. The scale is an asymmetry problem. A developer working with an agent can produce five, six, or more pull requests in a day, but review, validation, and integration have not gotten any faster. Remi Verschelde, who maintains the Godot game engine, has described triaging AI slop as draining and demoralizing.

Projects that still welcome contributions are drawing lines in policy. FastAPI’s guidelines state that low-effort or low-quality pull requests are not accepted, and that AI-generated submissions may be closed and the accounts behind them blocked, according to a 2026 survey of contributor AI policies.

The Jazzband collective, which hosted 84 projects for 3,135 members over more than a decade, announced in March 2026 that it was sunsetting. Founder Jannis Leidel cited GitHub’s “slopocalypse,” the flood of AI-generated spam PRs and issues, as what made Jazzband’s open-membership, shared-push model untenable. Jazzband was designed for a world where the worst case was someone accidentally merging the wrong PR; a world where only 1 in 10 AI-generated PRs meets project standards breaks that assumption completely. In Leidel’s telling, even GitHub’s own response was a kill switch to disable pull requests entirely.

The Bottleneck Is Review, Not Generation

At first glance, rejecting AI PRs might seem like gatekeeping. The reality is more nuanced, and more dire.

Maintenance was already running on fumes. The New Stack reports that 60% of unpaid volunteer maintainers already struggle to keep up with the load they have. Jazzband’s wind-down post is unusually candid about why collective models didn’t fix that: for over ten years, every project transfer, lead assignment, and infrastructure decision ran through Leidel alone. He says he dropped the ball on organizing help, and that volunteers who stepped up quietly stepped back when there was no structure to support them. When he points to the XZ Utils backdoor as what happens when a lone maintainer burns out and someone malicious fills the gap, he is describing the same fragility from the security side.

Every hour a maintainer spends reviewing a low-quality AI PR is an hour not spent on security patches, feature development, or documentation. The economics run in one direction: generation got cheap, verification did not. A CodeRabbit analysis of 470 open-source pull requests, cited in the same report, found approximately 1.7 times more issues in AI-co-authored PRs than in human-written ones. The report also cites Agoda research finding experienced developers were 19% slower when using AI tools, accumulating what its researchers call “comprehension debt”: developers understand less of their own codebase as AI-generated code piles up.

The psychological toll shows up in maintainers’ own words. Stenberg writes that never-ending slop submissions “take a serious mental toll to manage and sometimes also a long time to debunk,” time and energy that is “completely wasted.” For volunteers, that is the job now.

Vouch: Gating on Trust Instead of Diffs

Hashimoto’s response is Vouch, a system designed to separate signal from noise in the contribution pipeline by gating on trust rather than on the content of a diff. Rather than banning AI contributions outright (a stance some maintainers take), Vouch makes participation itself conditional: trusted contributors “vouch” for newcomers through a checked-in trust file and GitHub Actions, so a project can require some prior standing before a PR from an unknown account gets a maintainer’s time. Hashimoto runs it on Ghostty.

The core mechanism is deliberately simple:

Explicit, recorded trust. The vouch list is a single flat file, one handle per line, trivially parseable with standard POSIX tools. GitHub Actions check whether issue and PR authors are vouched on open or reopen; bots and collaborators with write access are automatically allowed. Projects can auto-close PRs from unvouched or denounced users, and auto-close and lock issues. Collaborators can also vouch or denounce someone by commenting on an issue, which updates the trust file and commits the change.
Denouncement as a first-class verb. The file format and CLI support denouncing users with a recorded reason; the README’s own example reason is “Submitted AI slop.” Each project decides the consequences, and the system can run in a mode that allows unvouched users while still blocking denounced ones.
AI as the named problem. Vouch’s own description pins the change on “AI tools that allow people to trivially create plausible-looking but extremely low-quality contributions with little to no true understanding.” For over 20 years, the effort required to understand a codebase and submit a change filtered out low-quality contributions on its own. That filter is gone, so trust has to become explicit.

Vouch is released publicly on GitHub, with a FAQ, cookbook, and CLI, so other maintainers can adopt the same model. It was extracted from a trust system already running in the Pi project, is generic enough to run on any code forge (GitHub integration ships out of the box), and its trust-file format, which Hashimoto calls “Trustdown,” is meant to be specified so separate trust systems can eventually coordinate with each other, though he says he will not publish a specification until usage stabilizes. He also labels the whole thing experimental. The goal is not to stop people from using AI. It is to keep a human who understands the change, and is accountable for it, in the loop.

The Broader Landscape: What Projects Are Doing

Vouch isn’t the only response to the AI PR crisis. Across the open source ecosystem, the strategies cluster into patterns:

The Explicit Policy: Hashimoto’s own Ghostty project pairs the tool with a written AI policy. A 2026 study of contributor AI policies uses Ghostty as its exemplar: AI-generated contributions are allowed provided they are disclosed and include human involvement in the contribution process.

The Bug-Bounty Casualty: curl ended its bug bounty on January 31, 2026 after AI slop reports drove the confirmed-vulnerability rate below 5%, down from north of 15% in earlier years. As creator Daniel Stenberg put it, “not even one in twenty was real.” Over its life the program paid out more than $100,000 across 87 confirmed vulnerabilities. Security reports now go through GitHub’s private vulnerability reporting, with no monetary reward, and the project continues to immediately ban and publicly ridicule anyone who submits AI slop.

The Hybrid Model: Most policies land in the middle. Hugging Face’s transformers states that “AI-assisted contributions are welcome, but they must be coordinated, scoped, and verified to keep review load manageable.” Microsoft’s typescript asks contributors to disclose AI use in the PR description. At the restrictive end, the same study found 22% of the 118 policies it identified explicitly discourage AI use, from Mastodon’s general discouragement to copyparty’s flat ban on LLM-written code and PostgREST’s express prohibition on contributing AI-created content.

Automation-First: Stenberg notes that pull requests are “less of a problem” for curl than security reports, and the reason is machinery: the project doesn’t waste human time on a PR until the quality is good enough to earn green check marks from 200 CI jobs. Projects with strong automated verification can let machines absorb the first wave of filtering. That doesn’t help the projects without such infrastructure, which is most of them.

What Rejection Actually Measures

The debate over AI-generated PRs has run largely on maintainer accounts and aggregate merge rates. A study presented at the Mining Software Repositories conference in April 2026, “Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study,” examines whether those outcome labels reflect agent capability at all.

Hoshi et al. analyzed 11,048 closed agentic PRs from repositories with at least 500 stars, refined to 9,799 human-reviewed cases, and manually inspected a stratified sample of 717 to recover decision rationale from review interactions. The results cut against the assumption that rejection means failure. Only 35.7% of rejected PRs reflected clear agentic failures. Another 31.2% were blocked by workflow constraints such as duplicates, superseded changes, or test PRs, and 33.1% lacked any observable decision rationale, often closed silently without a comment. That last category deserves care: the authors are explicit that silent closures neither prove nor disprove agent failure, and should be excluded from precision-based evaluations rather than counted as either. Among merged PRs, 15.4% still required explicit reviewer involvement through feedback or reviewer-applied commits, and 5.5% showed no visible interaction trace at all. Most merges, 79.1%, completed with no observed feedback loop.

The paper also surfaces systematic differences across the five agents it studies (Copilot, Devin, Codex, Cursor, and Claude Code). Copilot and Devin PRs were more often embedded in reviewer-mediated workflows, while Codex and Cursor PRs were typically merged with minimal interaction. The rejection mix varied too: 47.8% of sampled Codex rejections were clear agent failures, against 24.2% for Devin, which was more often blocked by workflow. Claude Code contributed only 8 rejected PRs to the sample, so per-agent numbers carry real uncertainty. The authors’ own reading, in the paper, is that observed outcomes reflect the review environment, with its CI gating and contribution norms, as much as the agent itself. Integration pattern may matter as much as code quality.

For vendors selling autonomous coding agents, the takeaway is that “passes CI” is the wrong optimization target. The maintainer’s decision function includes factors no test suite can measure: whether the change respects project conventions, whether the scope matches the issue, whether the contributor will stick around to fix regressions. If these failure modes can be categorized from review artifacts, they can be surfaced automatically in forge-side interfaces before a human reviewer opens the PR. That would shift the filtering burden back to the platform, where it belongs, instead of leaving it on the maintainer’s inbox. The same problem shows up in evaluation work like SpecBench’s reward-hacking tests for long-horizon coding agents: agents learn to satisfy the visible signal, not the intent behind it.

Who Answers for the Code?

The traditional open source model assumed the person submitting a diff understood it. Policies are now negotiating that assumption explicitly, and the human-in-the-loop requirement documented in the policy survey is really an attribution rule: the contributor stays responsible. Selenium’s policy puts it flatly: “Human-in-the-loop is required: You are the author. You must read, review, and understand all AI-assisted output before requesting review.” picoclaw’s is blunter: “Using AI to generate code does not reduce your responsibility as the contributor.”

Enforcement is social, because open source licenses disclaim liability. Vouch’s trust file and curl’s ban-and-ridicule stance are the same instrument at different granularities, one recorded in a repository and one in a blog post. Neither settles who is at fault when an AI-written PR ships a vulnerability; the survey’s authors flag licensing and legal questions as still unexplored.

Best Practices for the New Normal

For maintainers navigating this landscape, several patterns are emerging as effective:

Clear Contribution Guidelines: Explicitly address AI usage. eslint requires disclosure in plain terms: “If you use AI to generate an issue or a pull request, you must clearly disclose this in your submission. This helps maintainers understand the context of the contribution and perform appropriate reviews.” sipeed/picoclaw asks every PR to grade its own AI involvement on three levels, from fully AI-generated to mostly human-written. Explicit rules cost little and give maintainers grounds to act on the worst drive-by submissions.

Disclosure Requirements: A study of 1,000 popular GitHub repositories identified 118 with written contributor AI policies; 78% of those allowed generative AI, 51% required disclosure, and 74% required a human in the loop. The mechanisms are concrete: name the tool, state the extent of assistance, use commit-message trailers such as Assisted-By:. Electron’s policy captures the spirit well: disclosure “helps facilitate productive code reviews, and is not used to police tool usage.”

Structural Controls: The policy survey documents a spectrum of harder measures: automatically closing pull requests, requiring contributors to be approved beforehand, checking whether a proposed change is already implemented, limiting pull requests per contributor, and at the far end no longer accepting pull requests at all, as lazygit and pocketbase have done. Vouch is the general-purpose version of the “approved beforehand” pattern.

Welcoming Without Lowering the Bar: Not every project responds with restriction. ohmyzsh tells contributors “AI tools can be pretty helpful for coding tasks, and we’re not here to gatekeep how you get your work done,” while still asking that AI use be mentioned in the PR description. GitHub’s spec-kit “welcome[s] and encourage[s] the use of AI tools.” Since 78% of the surveyed policies allow AI while 51% require disclosure and 74% require human oversight, welcome and guardrails usually travel together.

The Path Forward

AI-generated PRs aren’t going away. If anything, they’ll become more sophisticated and harder to detect. The question is how to structure processes so AI improves rather than overwhelms human collaboration.

Vouch represents one vision: verify human engagement, preserve the efficiency benefits of AI tooling, and make trust explicit. The empirical work from Hoshi et al. points in a complementary direction: if maintainers’ rejection reasons can be categorized, they can be automated, and the filtering can happen before a human wastes time on a bad PR. The policy survey adds the unglamorous middle: say whether AI is welcome, require disclosure, name a responsible human. Other projects will find their own balances. What matters is addressing the problem deliberately rather than letting it fester. The harder version of this problem is the open-source health-score blind spot: the projects most at risk are the ones whose maintainer load never shows up in a dashboard until they quit.

The maintainers keeping our digital infrastructure running deserve systems that support them, not spam that drowns them. Vouch is a start. The data to make these systems better is arriving. The rest is implementation.

Have thoughts on AI contributions in open source? Join the discussion or suggest corrections via our community channels.