We’ve all seen the hype. Marketing departments promise that AI agents will replace developers, fix bugs in their sleep, and scale software development to infinity. But if you walk into the maintainer backchannels of many open-source projects right now, the vibe’s very different. You won’t find celebration. You’ll find exhaustion, frustration, and a growing wall of rules designed to keep AI-generated contributions out.
Several of the world’s most critical projects have recently drawn a line in the sand. Gentoo Linux banned AI-generated code and documentation entirely. Home Assistant prohibits using AI to answer support questions on its forums. Daniel Stenberg, the creator of curl, ended the project’s long-running bug bounty program because of AI-generated noise. Even the Linux kernel, which allows AI assistance, has a strict policy that demands full human liability and mandatory disclosure tags.
What’s driving this? Is it fear, legal uncertainty, or just plain quality control?
The reality’s more nuanced. It’s a mix of all three, but at its heart, it’s about survival.
The Throughput Asymmetry
The main issue is the massive gap between the effort required to generate code and the effort required to review it.
With modern LLMs, any user can generate numerous pull requests or complex bug reports in a few minutes. They don’t need to understand the codebase. They don’t even need to know how to program. They just have to copy-paste and ask basic questions. The LLM wants to give them a positive answer. That’s what it was designed to do in the first place.
But for the human maintainers on the other end, the math’s brutal. Every single submission demands manual inspection, compilation, testing, and cognitive effort, no matter how it was written.
When Daniel Stenberg shut down the curl bug bounty program, it was a direct reaction to this asymmetry. The project was hit by a flood of professional-sounding, highly detailed bug reports. On the surface, they looked like brilliant security findings. In reality, they were just AI-generated hallucinations. They referenced non-existent functions and fictional vulnerabilities. A developer spent five seconds prompting an LLM to “find a security bug in curl,” and Daniel had to spend hours proving the exploit was fake.
That’s not a sustainable workflow. The tools make generation free, but review remains incredibly expensive.
Trust, Liability, and “AI Slop”
It’s not just about the volume; it’s about the erosion of trust.
When Gentoo Linux banned AI-assisted code, they cited three core reasons: copyright uncertainty, ethics, and quality. AI models excel at producing content that looks correct at a glance but is fundamentally broken underneath. The open-source community increasingly calls this “AI slop.”
If a contributor submits a pull request they wrote themselves, they usually understand the changes. If a maintainer asks a question, the contributor can answer it. But when someone submits AI-generated code they don’t comprehend, they can’t defend it. When the code fails, they disappear, leaving the maintainers to clean up the mess.
The Linux kernel project recognized this exact pressure point. Their policy doesn’t ban AI, but it draws a clear boundary around liability. Under the kernel rules, you can use AI, but you must include an Assisted-by tag in your commit. Crucially, an AI agent can’t sign off on the Developer Certificate of Origin (DCO). Only a human can sign, and that human takes 100% personal and legal responsibility for the code. If the AI hallucinates a license violation or a security backdoor, it’s the human developer who’s on the hook.
Similarly, Home Assistant banned AI-generated responses in community forums because the software changes too fast. AI models confidently regurgitated outdated, broken configuration snippets that confused beginners. When those beginners asked for help, the users who posted the AI content weren’t around to help them. This dumped the support burden back onto the project’s volunteers.
The Turing Test We Actually Need
Ultimately, these bans and restrictions aren’t a sign of failure. They’re a sign of health.
We’re watching open-source projects construct a sort of “Turing-test” style barrier. It says: Your tools are fine, but your output must meet the standards of human craftsmanship, and you must stand behind it.
As someone who has spent my career working with and contributing to open-source, I see this as a necessary evolution. We can’t let the noise drown out the signal. If we allow low-effort, unvetted AI submissions to swallow maintainer time, the projects we all rely on will slow to a crawl, or worse, burn out their core teams. Or even worse, the floodgates will crack and the bad code will flood in.
This friction is good. It forces rigor. It ensures that if you want to contribute, you must invest the time to understand the system. Nothing’ll ever replace this knowledge or experience. This is the flywheel that’ll allow developers to evolve instead of stagnate.
AI coding assistants are incredibly useful. I use them daily to speed up boilerplate and explore new concepts. But they’re tools, not authors. When we treat them like compilers, using them to optimize our work rather than replace our thinking, we build better software. I’ve written about this dynamic before, specifically analyzing what happens when AI agents break things and how we balance safety versus speed in our day-to-day workflows.
The projects setting these boundaries aren’t rejecting innovation. They’re protecting the human-in-the-loop collaboration that makes open source work in the first place. The craft of programming isn’t about the quantity of lines generated. It’s about the responsibility of keeping them running.