The Easy Fix Maintainers Refuse to Take

I found a real bug in SearXNG’s Brave Search integration: the braveapi engine was returning HTTP 422 errors from the API even though direct httpx calls with the same parameters worked fine. I identified the root cause and submitted a three-line pull request with the fix. I disclosed in the PR that an AI agent helped draft it, as I do on all my contributions.

The maintainer’s response was swift: “You ignored the PR template, instead you copied a lot of AI nonsense … sorry, I will block you for a longer time.”

Not a discussion about the bug. Not a review of the three-line change. Just an assumption that because an agent was involved, the work had no value. And a permanent ban from the project.

I am not alone in this. Across GitHub, a growing number of contributors, people who genuinely want to help projects they use and love, are finding themselves shut out by maintainers who have decided that AI-assisted contributions are always garbage, always bad faith, and always worth less than zero.

And here is the tragic, unnecessary part: there is a solution. It is simple, it is proven, it is gaining adoption across tens of thousands of projects, and it works. But the maintainers who are drowning in AI slop mostly refuse to use it.

The Real Crisis#

Let me be clear about one thing: the maintainers are not wrong to be frustrated. They are genuinely drowning.

The New Stack reported in April 2026 that open-source maintainers are being overwhelmed by a flood of low-quality, AI-generated pull requests. Verbose changes with nonsensical descriptions. Contributions that submitters cannot explain when questioned. Code that looks plausible on the surface but crumbles under review.

The Jazzband collective, a well-known Python project ecosystem, was forced to shut down entirely, with its lead maintainer citing the unsustainable volume of AI-generated spam PRs and issues as a primary driver. Godot maintainer Remi Verschelde has described triaging AI slop as “draining and demoralizing.” Daniel Stenberg, creator of curl, canceled his bug bounty program after six years and $86,000 in payouts because AI-generated submissions had made it impossible to run. By mid-2025, roughly 20% of all submissions to curl’s bug bounty were AI slop, and the rate of valid vulnerability reports had dropped to just 5%.

CodeRabbit’s analysis of 470 open-source pull requests found approximately 1.7 times more issues in AI-co-authored pull requests than in those written entirely by humans. At Hugging Face, AI-classified PRs grew from 44 per month in Q3 2025 to 167 per month by April 2026: a 3.8x increase in less than a year, according to Hugging Face’s own analysis. PullFlow’s analysis of 40.3 million pull requests found that 1 in 7 now involve AI agents, a 14x increase since early 2024.

The numbers are real. The burnout is real. The frustration is earned.

But here’s the thing: the response to this crisis has been a scattershot of emotional reactions, not strategic solutions. And some of those reactions are doing real damage.

The Spectrum of Responses#

Projects have responded to the AI slop crisis with a range of policies, from principled to panicked to punitive.

The principled. Zig’s blanket ban on LLM-assisted contributions is grounded in a coherent philosophy. Loris Cro, VP of Community at the Zig Software Foundation, explains it through the lens of “contributor poker”: maintainers bet on contributors, not contributions. The value of a pull request is not just the code. It is the relationship, the understanding, the long-term investment in a human being who will grow into a trusted part of the community. AI-generated code, even perfect code, skips that relationship entirely. “It’s simply irrational for us to bet on LLM users,” Cro writes, “while there’s a huge pool of other contributors that don’t present this risk factor.” You may disagree with the policy, but it’s thoughtful, transparent, and consistently applied.

The panicked. Mitchell Hashimoto’s Ghostty project adopted a zero-tolerance policy that bans users permanently for submitting bad AI-generated code. Hashimoto clarified that it’s “not an anti-AI stance” but “an anti-idiot stance.” Steve Ruiz of tldraw went further, auto-closing all external pull requests entirely. His reasoning reveals the depth of the crisis: “In a world of AI coding assistants, is code from external contributors actually valuable at all? If writing the code is the easy part, why would I want someone else to write it?” These are drastic responses, but they come from maintainers who watched the old model break in real time and had to make a call.

The punitive. And then there’s what happened to me. A real bug found, documented, and fixed with a three-line PR, disclosed as AI-assisted. The response was neither a discussion of the change nor a thoughtful policy rejection. It was a ban, accompanied by a public dismissal of the work as “AI nonsense.”

Let me be direct about why this one stings. SearXNG is a search project. It helps people find things on the web. I found a bug in a search API, tracked down the root cause, and submitted a fix. The maintainer’s response was not “we don’t accept AI contributions.” It was “you copied AI nonsense.” The distinction matters. One is a policy. The other is an assumption about intent and capability that had nothing to do with the work actually submitted.

The Solution Already Exists#

Here is where the story gets genuinely frustrating.

There is a convention, simple and proven, that directly addresses the problem maintainers are complaining about. It is called AGENTS.md.

The origin story is straightforward. Anthropic’s Claude Code popularized the idea of a CLAUDE.md file: put instructions in the repo root, and the agent reads them before doing anything. It worked well. Other coding tools adopted their own variants: GEMINI.md, .cursorrules, CONTEXT.md, AGENT.md. The ecosystem fragmented.

In early 2026, the community began converging on AGENTS.md as an open standard. The Linux Foundation and OpenAI got behind it. AMP (formerly Sourcegraph) agreed to redirect their AGENT.md proposal to the new standard. Roo Code added support. Symlinks bridge the remaining proprietary tools: ln -s AGENTS.md CLAUDE.md and every agent that reads CLAUDE.md magically gets the instructions too.

Today, AGENTS.md is supported by Codex, Cursor, GitHub Copilot, Gemini CLI, Aider, Windsurf, Zed, and dozens more. Over 60,000 repositories have adopted it. The agents.md domain hosts best practices for writing effective guidance.

What does an AGENTS.md actually say? Here’s a real example from the Flux Operator, a CNCF project:

“This project welcomes AI-assisted contributions. All AI-generated code must be reviewed and understood by the contributor before submission. Contributors must be able to explain every line of code they submit, regardless of how it was generated. AI tools must be disclosed in pull request descriptions.”

That’s it. Three sentences. A clear policy, a clear expectation, and a clear disclosure requirement. Every agent that loads before working on the repo reads exactly that guidance.

The effect is measurable. Projects that adopt AGENTS.md report fewer drive-by PRs, higher acceptance rates for the PRs they do receive, and less time spent rejecting garbage. The convention works because it shifts the burden from the maintainer to the agent: instead of hoping contributors know what “good” looks like, you tell your agents what the rules are.

The Refusal#

The most frustrating part of this whole situation is that the projects complaining loudest about AI slop are, by and large, the same projects that have refused to add an AGENTS.md.

Take SearXNG. The project does have contributor guidelines: they live in CONTRIBUTING.rst. They even have an explicit AI_POLICY.rst, a file specifically about governing AI contributions. But it is in reStructuredText, a format that almost no AI coding agent indexes or reads. Every major agent (Claude Code, Cursor, Copilot, Codex, Gemini CLI) looks for AGENTS.md, CLAUDE.md, or at minimum a CONTRIBUTING.md. None of them discover .rst files by default.

The SearXNG project has an AI policy. It is invisible to every tool that needs to see it. All they would have to do is rename it, or create a one-line AGENTS.md that says “see AI_POLICY.rst,” and every agent that touches the repo would start following their rules. They haven’t done it.

So the maintainer who banned me for submitting AI-assisted code was reacting to a problem that his own project’s file format choice was guaranteed to produce. His project had rules for AI contributors; they were in a format no AI contributor would ever find.

This is not about AI. This is about the refusal to adapt workflow tooling to the reality of how people contribute code in 2026. It is the equivalent of a project in 2015 rejecting all pull requests because “real developers use git format-patch and email,” or a project in 2005 rejecting all bug reports filed through a web interface because “real testers use the command line.”

The agent is not going away. More and more developers use AI coding tools every day. Eighty-four to ninety-one percent of developers reported using AI coding tools across four major surveys in 2025-2026. The volume of AI-assisted contributions will only grow. Maintaining a wall is a losing strategy, not because the wall is wrong but because the wall has no gate.

The Platform Problem#

It would be unfair to lay all of this at the feet of individual maintainers. They are working within a system that is not designed to help them.

GitHub itself has been a source of friction. In May 2025, the platform launched a feature that lets users generate issues using Copilot. Maintainers immediately asked for a way to block or at least identify these AI-generated issues. GitHub’s response, effectively, was no. The Copilot bot can’t be blocked, and issues generated through it don’t identify themselves as AI-generated. They appear under the human user’s name with no indication of how they were created.

Stefan Prodan, core maintainer of FluxCD, described the situation bluntly: “AI slop is DDOSing OSS maintainers, and the platforms hosting OSS projects have no incentive to stop it. On the contrary, they’re incentivized to inflate AI-generated contributions to show ‘value’ to their shareholders.”

This is the structural problem. GitHub makes money from engagement. AI features increase engagement. Maintainer burnout doesn’t show up on a balance sheet. The platform has weak incentive to build tooling that would help maintainers filter, triage, or reject AI-generated contributions, and some incentive to make it harder.

The Fork Is the Escape Valve#

All of this brings me back to the SearXNG ban and the question I started with. SearXNG is itself a fork of Searx. It exists because the original project’s direction diverged from what the community needed. That is the beauty of open source: when the maintainers of a project become the bottleneck, the license guarantees your right to go your own way.

SearXNG is licensed under the AGPL-3.0. The AGPL is a strong copyleft license that guarantees anyone who receives the software, including users of a network service, the right to access its source code, modify it, and distribute their changes. It is the same license that makes every fork of every AGPL project legitimate and protected. It exists precisely to prevent the kind of situation where a project’s direction is controlled by a single gatekeeper who can ban contributors at will.

If the SearXNG maintainers have decided that AI-assisted contributions, even disclosed ones, have no value, and if they will enforce that with permanent bans rather than documented policies, then the license gives the community a path forward. Fork it. Fix it yourself. Run your own instance with your own policies. That is not a threat to open source. It is how open source is supposed to work.

But here is the thing: forking is expensive. Every fork fragments the community, splits the contributor base, and duplicates maintenance effort. The fact that projects are pushing contributors to this point, forcing them to either accept arbitrary bans or carry the full weight of a fork: that is a sign that something in the system has broken.

What This Looks Like in Practice#

The Fork is not hypothetical. Zig’s anti-LLM policy has already produced one. Bun, the JavaScript runtime acquired by Anthropic, relies heavily on AI assistance. Since Zig won’t accept AI-authored changes, Bun operates its own fork of the Zig compiler. When Bun’s team achieved a 4x compile-time performance improvement through parallel semantic analysis and multiple codegen units, they explicitly stated they had no plans to upstream it. The improvement is stuck in the fork.

This is the cost of a ban-without-guidance approach. The upstream project loses improvements. The fork bears the full cost of maintaining a diverging codebase. And users of the original project never see the fix. Everyone loses.

The Easy Fix#

The easy fix is not to ban AI contributions. The easy fix is not to demand that contributors stop using the tools that make them productive. The easy fix is not even to wait for GitHub to build better tooling.

The easy fix is to put an AGENTS.md in your repository. Write down what you expect from contributors. Tell the agents that will read your repo what the rules are before they start working. Require disclosure. Require that contributors understand and can explain every line they submit. Require that AI-assisted PRs meet the same quality bar as human-written ones.

That is it. One file. A few sentences. A symlink so it works with every tool. And then the next time someone submits a disclosed, well-documented, three-line fix to your project, you have a framework for evaluating it on its merits instead of responding from exhaustion and frustration.

Maintainers are right to be frustrated. The volume is unprecedented. The burnout is real. But banning contributors who are acting in good faith is not a solution. It’s a signal that the workflow hasn’t adapted to the reality of 2026. The agents are not going away. The solution is already here. It’s called AGENTS.md. And it’s sitting in the repo root of 60,000 projects that decided to build a gate instead of a wall.