Open source has never been as democratic as it seemed. Behind every popular repository, a tiny group—often just one or two people—carries the weight of maintaining code that millions depend on. This asymmetry has always been uncomfortable, but it worked because contributing required effort: you had to understand the codebase, reproduce bugs, and risk public embarrassment. Now, AI agents have obliterated that friction. The result is a flood of low-quality pull requests that threaten to break the very model of open source collaboration.
The Rise of AI-Generated Contributions
The problem is not hypothetical. Mitchell Hashimoto, the founder of HashiCorp and a figure revered in open source circles, has publicly considered closing external pull requests to his projects entirely. His reason is not a loss of faith in open source but a deluge of “slop PRs” generated by large language models and their agentic helpers. These pull requests are often technically plausible—they compile, they pass basic tests—but they lack context, trade-offs, and historical understanding. Flask creator Armin Ronacher calls this “agent psychosis”: developers become addicted to the dopamine hit of agentic coding, spinning up agents to run wild through their own projects and everyone else’s.
The industry is already seeing consequences. The OCaml community recently rejected an AI-generated pull request containing over 13,000 lines of code. Maintainers cited copyright concerns, lack of review resources, and the long-term maintenance burden. One maintainer warned that such submissions could bring the pull request system to a halt. Even GitHub, the host of the world’s largest code forge, is exploring tighter pull request controls and UI-level deletion options. When the platform itself considers a kill switch for contributions, the problem is no longer a niche annoyance—it is a structural crisis.
The Economics of Review
The core issue is an asymmetry of economics. It takes a developer roughly 60 seconds to prompt an AI agent to fix typos and optimize loops across a dozen files. But reviewing those changes—checking for obscure edge cases, ensuring alignment with the project’s long-term vision, verifying that the generated code does not introduce subtle bugs—can take an hour or more. Multiply that by hundreds of contributors all using personal LLM assistants, and the maintainer’s workload becomes unsustainable. The barrier to producing a plausible patch has collapsed, but the barrier to responsibly merging it has not.
This is a well-known pattern in open source. The concept of “bus factor” has long highlighted how few people actually maintain critical infrastructure. Researchers at Brookings have documented that most software dependencies rely on unpaid labor. Now, AI is accelerating the burnout that already plagued maintainers. When every external contribution arrives prepackaged from a machine, the human cost of curation skyrockets. The result is that maintainers are walking away or closing their projects to outside involvement.
The Death of Small Libraries
The impact is especially acute for small, low-value utility libraries. Nolan Lawson, author of blob-util—a JavaScript library with millions of downloads that helps developers work with Blobs—argues that the era of such libraries is ending. In the past, developers used blob-util because it was easier to install the library than to write the utility functions from scratch. But with Claude and GPT-5, developers can simply ask the AI to generate a snippet in milliseconds. Why take on a dependency when you can generate the exact code you need on the fly?
Something deeper is lost in this shift. These libraries were educational tools; developers learned by reading how others solved problems. When ephemeral AI snippets replace stable libraries, the teaching mentality that Lawson believes is the heart of open source evaporates. We trade understanding for instant answers. This leads to another provocation from Ronacher: we should just build it ourselves. He suggests that if dependencies bring constant churn, the logical response is to retreat into self-reliance—using AI to help, but keeping the code inside your own walls. The irony is that AI may reduce demand for small libraries while simultaneously increasing the volume of low-quality contributions into the libraries that remain.
The Great Bifurcation
All of this points to a bifurcation. On one side, massive enterprise-backed projects like Linux or Kubernetes will survive and thrive. They have the resources to build AI-filtering tools, employ full-time maintainers, and absorb the noise. These are the cathedrals of the open source world, guarded by sophisticated gates. On the other side, smaller “provincial” projects—run by individuals or small cores—are likely to stop accepting external contributions altogether. They simply cannot afford the overhead of reviewing AI-generated driftwood.
This is not a new pattern. Open source has always had a long tail of abandoned projects. But AI accelerates the process. The barrier to contribution has never been lower, but the barrier to meaningful contribution has never been higher. The result is a redefinition of what “open” means. We are moving away from the era of radical transparency—anyone can contribute—to an era of radical curation. The only people who will matter are those who actually write the code with human understanding, not those who prompt a machine to do it for them.
Redefining ‘Open’
The irony is thick: AI was supposed to make open source more accessible, and it has, in a shallow sense. But in lowering the barrier, it has also lowered the value. When everyone can contribute, no one’s contribution is special. When code is a commodity produced by a machine, the only scarce resource is human judgment—the ability to say no. The future of open source may belong to projects that are hardest to contribute to. They will demand high levels of human effort, human context, and human relationship. They will reject the slop loops and the agentic psychosis in favor of slow, deliberate, and deeply personal development.
The bazaar was a fun idea while it lasted, but it couldn’t survive the arrival of the robots. The future of open source is smaller, quieter, and much more exclusive. That might be the only way it survives. We don’t need more code; we need more care—care for the humans who shepherd communities and create code that endures beyond a simple prompt.
Source: InfoWorld News