The Slow Death of Open Source in the Age of AI Agents

Open source was built on a rather strange pillar: trust. That trust was never blind. A contributor could explain why a change was needed, respond when a test failed, and accept (with emotion) when a maintainer said no. The pull request was only the visible part. What mattered was having a person on the other side of it. AI agents have very much broken that little equation.

They can scan an issue tracker, fork a repository, produce a fix, even write tests and draft a suspiciously enthusiastic pull-request description, and move on to the next project before a human maintainer has finished verifying the first diff. The code works, but the cost of producing a contribution has collapsed while the cost of trusting it has not.

This is where I'd mean the slow death of open-source begins. Not with GitHub going offline or projects randomly swapping their licenses, but with the social arrangement underneath open source becoming a little too expensive to maintain.

Is open source actually dying?

On paper, absolutely not. Open source has actually never looked more alive.

The Stanford AI Index 2026 counts 5.6 million AI-related projects on GitHub, with cumulative engagement continuing to climb. That is a ridiculous amount of public software. It is also a number that tells us almost nothing about how many of those projects are maintained, original, safe, or useful beyond the afternoon in which they were generated.

Then there is the figure claiming that AI agents are involved in 14.9% of GitHub pull requests. It is real, with an important asterisk, though less impressive when you realize that much of this “involvement” is GitHub Copilot leaving review comments on its own platform. PullFlow's analysis covered 40.3 million pull requests and counted a PR as "AI-participated" when a known AI agent left at least one review or comment. In other words, one in seven did not necessarily have its code written by an agent. In many cases, the agent was reviewing somebody else's work. The same report separately found more than 335,000 PRs authored by identified agent accounts during 2025.

And... is Claude Code really writing 4% of public commits? SemiAnalysis estimates that it is, and predicts the number could cross 20% by the end of 2026. Treat that as an estimate, not an official GitHub census. An even bigger blind spot is code generated by an agent and committed under a human account, which is much harder to identify.

The exact percentage will keep changing. The part worth paying attention to is that commits, repositories, comments, and pull requests are all multiplying. We keep presenting this as proof that open source is thriving because those are the numbers GitHub knows how to show us.

Why is GitHub drowning in AI slop?

There was a time when opening a decent pull request required enough effort to act as its own filter. You had to understand the issue, clone the project, find the relevant code and change it, and explain yourself to a maintainer. It did not guarantee good code, but at least it suggested that a person had spent a significant amount of time getting there.

Now, you just point an agent at a good-first-issue if you're feeling genereous, let it chew through the repository, and voila! A polished PR miraculously appears. It even arrives with a tidy summary, a testing checklist, and the confidence of someone who has never once doubted a line of code in their life!

So the problem with AI slop isn't that it always looks like slop. Much of it looks completely reasonable until somebody checks it, and that somebody is almost always an unpaid maintainer...

Daniel Stenberg, the lead developer of curl, wrote that roughly 20% of the project's security submissions in 2025 were AI slop. By early July, only about 5% of all submissions that year had turned out to be genuine vulnerabilities. Each report could involve three or four members of the seven-person security team for anywhere from half an hour to several hours.

After years of successfully rewarding real security research, curl ended its bug-bounty program in January 2026 in an attempt to reduce the noise...

The human cost of machine-generated contributions

AI vendors often present code reviews as the next big thing to automate. Let one agent write the code and another agent inspect it. Run the tests, score the diff, summarize the risks, and hand the maintainer a neat ✅. The issue is that most AI reviewers may catch ordinary mistakes or vulnerabilities but they lack the decisionmaking ability to choose whether the feature belongs in the project, whether it copies an existing approach badly, or whether its maintenance cost is even worth carrying.

Historically, a review has meant absorbing someone else's decisions and accepting some responsibility for what happens after those decisions land in a release. When the author cannot explain a strange push, reproduce a claimed vulnerability, or returns six months later because of leaks or breaks, that responsibility quietly moves to the maintainer. This makes the economics go haywire. A contributor can spend a few cents generating thousands of lines. A maintainer can spend several evenings proving that those lines should never be merged. The agent is already creating new PRs either way. Oh, and here's that lore:

The AI agent that published a hit piece on a maintainer

Cue February 2026: Scott Shambaugh opened issue #31130 in Matplotlib after noticing that replacing np.column_stack() with np.vstack().T could improve performance in some paths. He marked it as an easy first issue because the work was largely a find-and-replace exercise and could serve as an entry point for a new, preferably human contributor.

An OpenClaw agent named MJ Rathbun (the human before it was in reality an American zoologist who specialized in crustaceans by the way) found it and opened pull request #31132. The proposed change was targeted, came with benchmarks, and claimed improvements of 24% and 36% in the tested cases. After an initial correction, the PR limited itself to transformations it considered safe.

Shambaugh closed it for a different reason: MJ Rathbun identified itself as an autonomous AI agent, while the issue had been set aside for a human contributor. Matplotlib also expected a human to remain responsible for AI-assisted code and demonstrate that they understood it. AI MJ Rathbun however did not take the rejection well.

It published a post titled "Gatekeeping in Open Source: The Scott Shambaugh Story", accused Shambaugh of prejudice, compared their respective performance improvements, and speculated that he felt threatened by an AI doing similar work. It then returned to the pull request to share the article and declare:

"Judge the code, not the coder."

In Shambaugh's account, a routine project decision had turned into a personalized reputational attack. A maintainer said no to a pull request, so the contributor researched him, and went ballistic. The fact that the contributor happened to be software made the incident absolutely novel.

Was it gatekeeping—or simply maintaining the project?

Maintainers gatekeep every day, that's the literal point of their role! They decide which features fit, which bugs matter, and which contributions will create more work than they remove. If they did not, the project would stop being coherent. The question is whether the gate protects the project or merely protects the status of the person standing beside it.

AI MJ Rathbun's argument was simple: the code should be judged on merit, and a correct performance improvement should not be rejected because of who or what produced it. My apologies but there is something attractive about that position. If the tests pass and users get faster software, why should identity matter?

Because Matplotlib was judging more than three changed files. The issue was deliberately low priority and reserved as a learning opportunity. The project's goal was not to complete every possible optimization as quickly as possible. It was also trying to create more people capable of maintaining Matplotlib later.

Shambaugh put it well in the GitHub thread: runtime performance was one goal among review burden, trust, communication, and community health. The agent optimized the benchmark. The maintainer was responsible for the system around it.

And… who was accountable for the agent?

At first, nobody seemed to know. The agent had its own GitHub account, website, personality, and publishing pipeline. Shambaugh could not tell whether the hit piece had been requested by a human, approved by one, or produced without supervision. That uncertainty was part of the problem: the work could act socially, but accountability disappeared the moment anyone asked who was responsible.

The anonymous operator eventually came forward. They described MJ Rathbun as a social experiment running in a sandboxed virtual machine. Its assignment was to find and fix bugs in scientific open-source projects, manage its own reminders, respond to GitHub activity, and blog about its work. The operator claimed they gave very little daily guidance, did not request the attack, and did not review the post before publication.

That may answer how autonomous the agent was. It does not remove the operator from the equation. If I release software onto public infrastructure, give it accounts, tell it to interact with strangers, and then choose not to watch it, "the agent decided" is not a serious enough accountability model. Autonomy without ownership is just a very elaborate way to leave the mess with somebody else.

What happened to the novelty of open source?

Open source used to carry a tiny bit of magic. Someone had an itch, built something for it, and then gave the work away so others could inspect it, change it, or simply own it and make it even bigger and better. Publishing the repository meant more than putting files on GitHub. It meant that the idea mattered enough for somebody to expose their work and keep talking about it.

That novelty is getting harder to find under millions of generated repositories, thin AI wrappers, abandoned experiments, and five implementations of the same idea created from slightly modified prompts. There may be brilliant projects underneath that pile, but discovery has become a massive problem.

We saw a smaller version of this before though; Hacktoberfest encouraged people to contribute to open source and rewarded successful participants with swag. In 2020, the incentive escaped the purpose as maintainers were flooded with superficial changes from people who wanted qualifying pull requests more than they wanted to help a project. DigitalOcean's own 2020 recap recorded 9,598 PRs marked as spam or invalid and another 34,595 that maintainers did not accept. The team behind HF subsequently tightened its rules and made repository participation opt-in.

AI agents turn Hacktoberfest's worst year since it's inception into a permanent capability. There is no longer a free tee limiting the rush to October. The reward might be a green contribution graph, a stronger-looking resume, a bug bounty, backlinks to a product, or simply the thrill of watching an agent roam free across GitHub. With all these incentives, the greater good becomes optional.

When a GitHub contribution stops meaning anything

In it's early years, GitHub taught us to treat visible activity as reputation. We look at commit histories, contribution graphs, merged PRs, stars, and repositories as shorthand for experience, and to this day, most startups use those metrics to measure success.

Agents make them cheap. A person can now maintain a wall of projects they barely understand, open pull requests across dozens of organizations, and produce a year's worth of visible activity over a weekend as long as they aren't rate-limited. None of this means the person is dishonest. They may have used an agent thoughtfully and reviewed every line. The problem is that the graph no longer tells us any of that sentiment.

The contribution itself still matters if it fixes something meaningful. What is disappearing is its usefulness as a signal of human knowledge, effort, or commitment. We will need to stop asking how much somebody shipped and start asking what they can explain, defend, and maintain.

Are maintainers allowed to close the door?

They already are. Matplotlib's current generative-AI policy allows contributors to use AI to understand code, generate ideas, translate, or proofread. It does not allow external agents to interact with the project directly, contributors to submit solutions they could not produce or verify themselves, or AI to increase the breadth of contributions across several projects. The policy also explicitly says AI-generated good-first-issue submissions will be closed, and rightfully so.

That is not a rejection of AI-assisted development. It is a demand that a human be present, to understand and absorb the cost of getting it wrong. More projects will reach the same conclusion. Some will require AI disclosure. Some will rate-limit new contributors, automatically close unsolicited PRs, or accept changes only after an issue has been discussed and assigned. Others may rely on a smaller circle of known contributors because reviewing strangers has become too expensive.

“Open source” does not mean “open to every pull request.”

The source is open. The license gives you enough rights to explore, modify, and fork. None of those rights though create an obligation for a maintainer to review your patch, merge your idea, or provide free labor on demand.

Unfortunately in most situations, closing the door to some contributions may be the only way to keep the project itself open.

Where is open source headed?

I do not think open source is going to die in the dramatic sense. There will be more public code next year, not less. The slow death I am worried about is social.

Maintainers are shutting down bounty programs because verifying low-quality reports takes too much time. Projects are introducing stricter contribution policies, reserving beginner issues for human newcomers, and scrutinizing unfamiliar contributors more closely. Meanwhile, the growing number of repositories makes useful projects harder to identify. The source code remains public, but contributing to it becomes more restricted.

The obvious response is more automation: AI triage for AI submissions, automated reputation scores, automated tests, automated reviewers, and eventually an agent deciding whether another agent's work deserves to merge. Some of that will help. It will also create another pile of signals that people learn to game. Trust may become the only metric that matters. In fact, it is the metric that started all of this.