The Road to Open Source Hell Is Paved With Good Intentions
That sounds like a good thing. Ask almost any maintainer, though, and they will tell you it is not. In fact, few would choose to start their open-source journey today.
Is this just resistance from a bunch of old fogies afraid of being replaced? Not exactly.
This post explains why, from the perspective of someone who has spent the last six years contributing to and maintaining large open-source projects.
"Claude, find something wrong with this project and fix it."
At first glance, this sounds almost generous. Someone is spending their own tokens to scan your project, find something wrong, and even propose a fix. Free compute, free labor. What maintainer would complain about that?
The first thing to understand is that every project is full of bugs, edge cases, and missing features. Before agents, there was a natural filter: if a problem was common or painful enough, eventually someone would spend their time bringing it to the maintainers’ attention, or even share a fix or feature implementation. That effort was itself a strong signal.
Now that filter is gone.
An agent can surface dozens of technically valid problems in minutes, regardless of whether anyone has ever encountered them in practice or cares about having them fixed. What used to be a signal of real user demand can now be generated on command.
In other words, real user needs are now buried under a flood of reports that are technically valid, but often irrelevant in practice.
If it’s technically correct, what’s the harm?
The answer lies in two things that are hard to appreciate until you have maintained a project for long enough: surface area and time.
Agents are very good at answering how do we change this? They are much worse at answering should we change this at all? Every new behavior, option, or feature expands what the project must understand, test, document, and support for years, so that judgment still requires a human maintainer.
And that brings us to the second cost: time.
Most open-source projects are understaffed. Even a five-minute review is five minutes not spent on a real user problem. If nine out of ten reports are manufactured, nine out of ten hours of triage are spent on manufactured user needs.
A small contribution is not free just because the patch is small. Someone still has to spend scarce attention deciding whether it belongs.
Why don’t maintainers just use agents too?
They do. A lot.
Agents help with triage, code review, regressions, debugging, and implementation. They let maintainers scale much further than before.
But not nearly as fast as they let contributions scale.
Generating a patch or feature can now take minutes. Deciding whether it belongs in the project still requires judgment: whether the problem matters, whether the added surface is justified, and whether it is worth maintaining for years.
Agents are still remarkably bad at that. Why they are bad at that is an interesting question in itself, and has a lot to do with how they are trained, but that is outside the scope of this post.
If changing the code is cheap for you, it is even cheaper for the maintainers
Historically, a contribution saved maintainers work.
If you wrote the implementation, the tests, or the documentation, the maintainer no longer had to do it themselves. Writing good docs, for example, could take hours; reviewing them might take minutes. The exchange was obvious: you contributed time, and the project got some of it back.
Agents have changed that balance.
For a maintainer with the right context and tooling, producing the implementation, tests, or documentation is now often the cheap part. They could generate most of it themselves.
So a contribution is increasingly less “I did this work so you don’t have to” and more “will you spend some of your time helping me do this with you?”
There is nothing wrong with that! Helping new contributors learn has always been part of open source. But it is a different transaction, and one that costs maintainer time rather than saving it.
And once maintainer time becomes the scarce resource, the question becomes: who do you spend it on?
The trust problem: why good faith is no longer the default
In most cases, maintainers could implement a contribution themselves faster and better. They deliberately do not, because helping someone else do it is part of how open source works: newcomers learn, gain context, and eventually become stronger contributors themselves.
But that only makes sense if there is actually a person on the other side worth investing in.
Maintainers are not particularly interested in helping someone else’s agent perform work their own agent could do better. Nor is there much value in mentoring someone who is merely acting as an intermediary between two agents.
So intent suddenly matters much more than the technical relevance of the contribution. Unfortunately, maintainers cannot reliably infer it. They fall back on imperfect heuristics, and those heuristics will sometimes reject sincere contributors.
That is especially painful because every maintainer was once a sincere newcomer too, benefiting from more experienced people taking their contribution seriously and assuming good faith. Losing that default is bad for everyone.
So, how should you contribute?
First: if you think putting your agent to work on random open-source projects is helping, stop. It is not. It mostly adds noise and destroys a signal maintainers used to rely on.
If you genuinely want to contribute, start by being a user. The best contributions usually come from people who actually depend on the project and understand where it hurts.
And finally, remember that the implementation itself is no longer as valuable as it once was. As a contributor, you are increasingly asking a maintainer for attention, feedback, and mentoring.
Would you eagerly spend twenty minutes reviewing a sixty-line essay you knew someone had generated in seconds and barely read themselves? Probably not. And code is no different.
So try contributing without an agent, at least at first. That may sound archaic, but it is the same reason we learn arithmetic before reaching for a calculator: the point is to build the mental model, not just produce the answer.
If you want a maintainer to invest human attention in you, invest some human attention first.
To conclude
AI is not the problem. Maintainers use it too, probably more than you do.
The problem starts when your "contribution" is nothing more than prompting an agent and handing the result to someone else to review, understand, and maintain.
We don't need more contributions. We need more contributors. 🤗
