Skip to main content

AI PR Spam Is Making Maintainer Trust More Expensive

· 5 min read
Gergely Sipos
Gergely Sipos
Frontend Architect

AI makes submitting a plausible patch cheap. Verifying it still takes human time. Recent restrictions from Sindre Sorhus and SWC expose that imbalance, but their responses and stated reasons differ. The question is not simply whether AI belongs in open source. It is who pays for verification.

Two restrictions, different boundaries​

On October 1, Sindre Sorhus announced: "Due to AI, I have disabled external pull requests on all my repos." He continues maintaining the projects and accepting issues. This closes a contribution channel, not the projects themselves.

In the follow-up discussion, Sorhus said contribution quality had been declining before AI, which accelerated the problem and worsened spam. He also described using AI heavily himself. That matters: his objection is not that any AI-assisted code is unacceptable. It is that accepting unsolicited patches has become too costly. Accepting issues does not establish an exception allowing issue-linked PRs.

SWC drew a different boundary. PR #12463, merged October 2, introduced a workflow for swc-project/swc that comments on and closes unauthorized PRs and gates CI. Eligible accounts include GitHub Bot accounts, collaborators with write, maintain, or admin permissions, and explicitly allowlisted usernames matched case-insensitively. Organization membership alone is not enough.

The workflow automatically closes unauthorized PRs after submission, but the cited PR left SWC's Collaborators only repository setting unchanged, so outside contributors could not create PRs until that setting was switched to Everyone. The contribution guide directs other contributors to open issues for bugs or improvements instead. Crucially, the cited PR and policy do not establish AI spam as SWC's motive. These changes illustrate restricted access to review; they do not justify saying both maintainers banned AI contributions for the same reason.

Review capacity is the bottleneck​

A patch is only part of a contribution. Someone must reproduce the problem, understand the context, check compatibility, and decide who owns the result after merging. A green test suite cannot answer whether the change belongs in the project or creates a maintenance obligation nobody wants.

For example, a generated fix for one failing input still needs checks for supported behavior, regressions, and simpler alternatives. A polished explanation does not answer those questions.

A trust gate protects time by limiting review to people whose judgment maintainers know. It can also exclude capable newcomers who have not yet earned that trust. That is a foreseeable trade-off, not a measured claim about contributor losses.

Open code does not entitle everyone to a maintainer's review. Still, closing the entry point can make the next generation of maintainers harder to cultivate.

Curl shows why the details matter​

Curl's experience concerns security reporting, not a PR ban. Daniel Stenberg described AI-generated junk reports that consumed investigation time without demonstrating real vulnerabilities. Curl later announced the end of monetary bug bounties on January 26, 2026, effective January 31, 2026, amid the reporting burden; Stenberg explicitly distinguished it from PR spam, which was not a comparable problem for curl.

By April, he described better-quality reports, with slop no longer dominant. In May, the workload still strained the project. Valid findings also require fixes, releases, and funding. These accounts do not isolate bounty removal or model improvements as the sole cause of better reporting.

Useful AI still requires accountability​

There are productive counterexamples. Mozilla's March 6, 2026 account of its work with Anthropic describes AI-assisted Firefox security findings backed by actionable test cases, human verification, and coordinated disclosure. The verified findings resulted in shipped Firefox fixes. Mozilla's security advisory independently credits findings made using Claude.

This shows that AI-assisted work can produce useful, verified results. It does not tell us the average quality of unsolicited AI-generated PRs. A coordinated security investigation and a drive-by patch have different review conditions.

The distinction is whether a submission carries evidence and human ownership. AI can help produce evidence. It cannot take responsibility when a contributor disappears instead of explaining why the change works.

Keep contributions open to responsibility​

For contributors, the practical response is straightforward:

  • Read the current contribution policy before preparing a patch. Respect restrictions even if you disagree with them.
  • Use an issue-first route when required. An accepted issue is not permission to bypass PR eligibility rules.
  • Understand, test, and explain the change yourself. Include a reproduction and evidence that the fix addresses it.
  • Disclose AI assistance when the project's policy asks for it. Do not substitute disclosure for verification.
  • Stay for review, revise the patch, and answer questions about compatibility and maintenance.

Maintainers can reduce wasted effort by stating eligibility clearly, explaining what belongs in issues, and documenting an admission process if they offer one. They are not obliged to create an onboarding program they cannot sustain.

The goal is accountability, not tool purity or predictions of doom. Cheaper submissions can make trust more expensive. Protecting today's review capacity may come at the cost of tomorrow's contributor pipeline.