Open source didn’t break because someone wrote bad code on purpose. It’s breaking because everyone is now writing good-enough code with zero friction, submitting it constantly, and expecting someone else to review it.
That someone is a maintainer. And they’re drowning.
The AI PR tsunami is already here
A few pieces started appearing this week that should alarm anyone who depends on open source. InfoQ ran “AI ‘Vibe Coding’ Threatens Open Source as Maintainers Face Crisis.” The Register covered a Go library maintainer calling GitHub’s Dependabot a “noise machine.” These aren’t the first warning signs, but they’re arriving faster now, and they’re not landing loudly enough.
AI tools have made contributing code nearly free, but they haven’t made reviewing it any cheaper.
A developer using Cursor or Claude can generate a PR in minutes. A maintainer still needs to read it, understand it, test it mentally against their architecture, and decide whether it belongs. That gap is the problem. The cost of creating a contribution has collapsed while the cost of receiving one has stayed the same.
The quality issue compounds this. A separate Register piece found that “AI has gotten good at finding bugs, not so good at swatting them.” If the tools themselves can’t reliably fix what they flag, we should think carefully about how much trust to extend to AI-generated patches submitted to someone else’s project.
The vibe coder isn’t the villain here
I’m not blaming people who use AI coding tools. I use them constantly. When I’m building something for myself, vibe coding is often the right call. I don’t need to fully understand every line if it’s my own project and I can debug it later.
But open source is different. When you submit a PR to a project you didn’t write and don’t maintain, you’re asking another person to spend their unpaid time on your code. The question isn’t whether your code works. It’s whether the maintainer has the bandwidth to evaluate it.
AI tools have made it easy to generate contributions faster than human reviewers can process them. The bottleneck hasn’t moved. Only the inflow has increased.
I don’t have a dataset that proves this. What I have is a pattern of signals: maintainers publicly complaining about AI-generated PR volume, projects adding explicit notes to their CONTRIBUTING.md that they won’t accept AI-generated code without disclosure, and my own experience maintaining small tools. The data will come. The anecdotes are already here.
What this looks like in practice
I’ve started noticing this when maintaining small projects. PRs come in that are technically functional, clearly generated with an AI tool (you can tell from the overly explanatory commit messages and the weirdly thorough docstrings on a two-line change), but they’re solving a problem that isn’t really a problem, or introducing a dependency I don’t want, or ignoring the conventions already in the codebase.
These aren’t terrible PRs. They’re noise. And noise is exhausting to process.
The maintainer’s job has quietly shifted from “guide the project” to “filter the firehose.” That’s not sustainable, especially for projects run by one or two people in their spare time.
The Dependabot comparison is worth being precise about. The Go maintainer’s complaint was about automated dependency bump PRs, not human-written AI code. Dependabot is a tool you can disable in repository settings. Human-generated vibe coding PRs are not. But Dependabot is still a useful reference point for what volume fatigue looks like at scale: the exhaustion, the interruption cost, the pressure to be polite about closing things that shouldn’t have been opened. Now imagine that dynamic coming from people instead of a bot. The social pressure multiplies.
What actually changes the equation
The solution isn’t “stop using AI to write code.” That ship has sailed. And it’s not purely on individual developers to vibe-code more carefully, though that matters.
The projects that survive this will be the ones that raise the bar for contributions explicitly. Not a CONTRIBUTING.md that says “be nice,” but actual friction: requiring issues before PRs, using Mergify rules to auto-close PRs without a linked issue or a test change, enabling GitHub’s first-time contributor review queue, adding a PR template that asks contributors to explain what problem they’re solving and whether they ran the tests.
None of this is exotic. Most of it is already in GitHub’s tooling. The real barrier is that maintainers feel impolite using it aggressively. That has to change.
It also means being honest that maintainer time is a limited resource being consumed faster than it’s being replenished. Not necessarily with money (though that helps), but with clearer expectations about what a reasonable contribution actually looks like.
The open source ecosystem built the foundation that AI development tools are standing on. GitHub Copilot, Cursor, every AI coding tool that generates Python syntax and imports libraries does so because millions of humans wrote and shared that code for free. Whether the tools that benefit most from open source are doing anything to protect it is a question worth asking.