Open Source Maintainers Need a Spam Filter for AI Labor

Currently Available: Need a skilled Software Developer for your next project?

Hire Me Today

Categories

LLM Open Source Software Development

Open Source Maintainers Need a Spam Filter for AI Labor

June 25, 2026 by Vincent Schmalbach

AI makes bug reports, pull requests, and security disclosures cheap to create, but expensive to review. Still need to reproduce issues, check compatibility, judge security impact, moderate discussion. When low effort AI submissions pile up, real bugs and vulnerabilities get lost in the shuffle. Open source needs well defined intake rules to protect the time of the maintainers. The filter broke because it used to take real effort to make coherent bug reports, context aware pull requests, and credible security disclosures. AI has taken away much of the filter. Bad reports are nothing new. But now it's cheap to make something look real. It still takes 30 minutes to 3 hours to determine if a report is real, often with several people reviewing it. The most expensive are the believable fake submissions. They have real functions, plausible code paths and believable impact so maintainers need to do some serious investigation before dismissing them.

Daniel Stenberg described this pattern well. Prior to the latest wave of AI-slop, the curl bug bounty program had received 477 submissions in about five and a half years, with some 15.4 percent of those submissions resulting in confirmed vulnerabilities. Some were legitimate bugs but not security issues, most were not applicable, and the worst reports were the plausible false ones because they took the most time to analyze, Stenberg said.

By mid-2025 the trend had been reversed. Approximately 20% of the submissions for 2025 seem to be produced by AI. The curl project got about 2 security reports per week, and only around 5 percent of the reports that year were real vulnerabilities. “Getting through each report took three to four security team members 30 minutes to three hours, or around 1.5 to 12 maintainer-hours, before it could be rejected,” Stenberg said. A small spate of bad reports could eat up a lot of emergency-level review time before a real vulnerability showed up.

The bounty program ended in early 2026. Over the years it had racked up dozens of confirmed vulnerabilities and big paydays. AI + bounty incentives made it too cheap to submit something plausible and the system broke. Later on, Stenberg went into what any replacement would need: account-age requirements, rate limits, labels for AI-generated submissions, abuse blocking, ability to publicly disclose invalid-report patterns etc.

Pull requests have the same review cost problem. In early 2026, tldraw started automating the closing of pull requests from external contributors, as the number of AI generated pull requests exploded. Many seemed acceptable but did not add much value. They passed CI, ignored contribution templates, skipped contributor license agreement steps, didn't understand the project design and stalled when review questions came.

Steve Ruiz wrote about this in his write up. He’s using AI and expects his team to use AI but external code without context or ownership still creates review debt. Before AI a fuzzy problem was often fuzzy because it was real work to make it a patch. With AI you can take the same problem, turn it into a believable diff in minutes, and now the maintainers have more reading to do, with no benefit. When you have an open pull request you are making a promise to the maintainers to read carefully. It doesn't make sense to put that burden on someone who contributed next to nothing and can't defend the change. “Code generation is cheap, reading and reviewing code is still the hard part,” one commenter on Hacker News noted. The distinction still matters. AI is helpful if you’re familiar with the code base and you’re performing a well-scoped task.

The discussion around the curl decision made one simple point: open source licensing and public hosting do not require maintainers to provide unlimited triage, free security analysis or constant human availability.

Elsewhere on the web, you see that same cost shift. AI crawlers make automated requests inexpensive. Bandwidth is paid for by site operators. In public repos it’s similar but maintainers spend time on review. An open repository doesn't have to be an infinite review endpoint.

AI is still helpful. AI-powered analyzers and researchers had found real value, as Stenberg later wrote. Tools like AISLE, ZeroPath and Codex Security have over time produced many bugfixes and several confirmed CVEs. He also said that AI pull request review bots help to make the curl code better.

Projects need more stringent take-in rules. Maintainers need a well defined intake policy and explicit permission to quickly close low-trust automated work.

For security reports, projects should require affected version and component, exact preconditions, minimal trigger or exploit sketch and local reproduction by the reporter. Keep the impact statement separate from speculation. Scanners or AI output is not a report, unless independently validated. Stenberg’s proposal has clear policy implications: rate limits, account-age gates, AI labels, repeat-abuser blocks.

For pull requests, require an accepted issue or prior discussion with a maintainer, and more than just a diff. The submitter should be able to explain design decisions, show that the change is tested, and be available to review. If they cannot, close the pull request.

Both require disclosure of AI up front. AI-assisted work is okay as long as the submitter understands the work, is able to explain it, and will answer questions. Ask for reproducers, failing tests, bisected commits, design rationale. If it does not look like that, close the submission.

When generation and submission are almost free, openness needs filters to remain usable. AI is powerful but bad incentives, weak ownership, missing verification and vague production boundaries turn that power into review debt. Use AI-assisted work where there is evidence, context and accountability. Close the rest quickly. Without that filter, the work that is most important is lost in a sea of low-effort AI work.

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