The “AI is destroying open source” headline has been recycled in some form every six months since 2022. The actual story is more interesting and less dramatic. Generative AI has changed who contributes to open source, what they contribute, and how the projects are governed. The trade-offs are real but the framing is usually wrong. This is a measured look at what is actually happening, drawn from running several small open source projects and watching the contribution patterns shift over three years.
What has actually changed
Three things shifted in the last three years.
First, the volume of low-quality contributions increased. Pull requests (proposed code changes submitted by contributors for the project maintainers to review and merge) that look plausible but do not compile, do not pass tests, or do not understand the existing architecture. Every maintainer I know has a horror story of a “PR from hell” (a pull request that looks reasonable on the surface but is full of subtle bugs or design errors) that took two hours to triage (sort through and decide what to do with) before the human realized the code was AI-generated nonsense with a real-looking commit message.
Second, the volume of high-quality contributions also increased. A new class of contributor showed up. People who could not write a parser by hand a year ago are now submitting well-structured PRs that fix real bugs, add tests, and respect the existing code style. They use AI to draft the code, but they understand what the code is doing and they are real participants in the project conversation.
Third, the governance patterns shifted. The maintainers of small to mid-size projects are now spending 30 to 50% of their review time on AI-assisted contributions. The work is real triage work. The “drive-by” PR (a one-off contribution from someone who does not stick around to iterate) is the dominant contributor type for many projects, and most of those drive-by PRs are AI-assisted.
The first two shifts cancel out partially. The third shift is the one with no obvious offset.
The new triage work
The actual burden on maintainers is triage, not rejection. Rejecting an AI-generated PR is a one-line response. Triage is reading the code, identifying the real issues, writing a useful review comment, and waiting for the contributor to either iterate or vanish. The cycle is longer than it was. Maintainers I have talked to report that their median review time per PR has roughly doubled since 2023, even for projects with active contributor bases.
Two patterns help. The first is a CONTRIBUTING.md (a file in the repository that tells new contributors how to submit changes) that requires a “human summary” of what the PR is doing and why. A surprising number of AI-only contributors do not fill this in, which makes the filter easy. The second is a “first PR” tag (a label that tells maintainers to look at a contributor’s first submission with extra care) that gets reviewed by a maintainer who has time to mentor, not just approve.
The projects that have done both of these are reporting sustainable review loads. The projects that have not are burning out maintainers, and the maintainers are the bottleneck. There is no amount of CI (continuous integration, an automated test-and-build pipeline that runs on every pull request) that fixes “the maintainer is the bottleneck.”
The trade-offs
Four costs nobody is talking about honestly.
- Maintainer time on triage. The median maintainer I have talked to spends 6 to 10 hours per week on PR review that did not exist as a category in 2022. Some of that is net new value, but a lot of it is sorting plausible nonsense from real work. The cost is real, and it falls on the same people who already had day jobs.
- Contribution concentration. The “drive-by” PR is real, but so is the opposite: a small number of AI-assisted contributors are now responsible for a disproportionate share of merged code. Project diversity of contributors has dropped in some cases, and the bus factor (the number of people who would have to leave a project before it stalled because no one else understood the code well enough to maintain it) is lower than it used to be.
- Code style homogenization. AI-generated code tends to converge on the same patterns regardless of which LLM produced it. The “obvious way to write a function” looks the same in 200 repos. This is fine for trivial code, and it is a real cost for projects that depended on stylistic diversity to surface design alternatives.
- Licensing uncertainty. The legal status of AI-generated code is unresolved in most jurisdictions. Most projects I know have updated their licenses to clarify that AI-generated contributions need a human author who can attest to the license, but the rule is hard to enforce. The risk is mostly theoretical right now, and it is mostly real in 5 years.
The cost-benefit analysis is project-specific. A library with 12 active maintainers and a clean architecture can absorb a lot of drive-by PRs. A project with 2 maintainers and a fragile core cannot. The honest framing is not “AI is destroying open source” or “AI is saving open source.” It is “AI has redistributed the work of open source, and the redistribution is hard for projects that were already understaffed.”
What works
Three patterns I have seen work in real projects.
- Pre-PR discussion for non-trivial changes. A short GitHub issue or Discord conversation before any code is written. The cost of the conversation is much lower than the cost of a misaligned PR. AI-assisted contributors who cannot explain their plan in a paragraph are usually the ones whose code does not match the project’s needs.
- Issue templates that filter by intent. A template that asks for the bug to be reproduced, the expected behavior, and the actual behavior, in that order. AI-generated issues that do not reproduce are easy to close. AI-generated issues that do reproduce are usually real bugs that the maintainer can fix themselves in 20 minutes.
- Reviewer rotation. A rotating list of maintainers who do PR review on a given day, with a hard cap on hours. Without the cap, the same 2 maintainers do all the review and they burn out. With the cap, the work is shared and the bottleneck moves to “how fast can we merge safe code,” not “how much review can one person do.”
None of these are novel. All of them were useful before AI. The point is that they are more useful now, and the projects that are doing them are weathering the shift better than the ones that are not.
What I would tell past me
If I could send a message back to the version of me that started a small open source library in 2022, I would say three things.
- Write a CONTRIBUTING.md that requires a human summary. It is the single most useful change you can make. The filter rate is high, the maintainer time saved is real, and the contributors who do fill it in are the ones worth working with.
- Set a hard cap on your review hours per week. The default behavior is to absorb the work. The cost of absorbing is your own projects, your day job, and eventually your willingness to be a maintainer. A cap is a feature, not a failure.
- Do not try to detect AI-generated code. You will fail. The signal you want is “is this contribution worth a maintainer’s time,” and the answer comes from the contributor’s behavior, not the code’s origin.
Trade-offs
Open source is not free in maintainer time, and the AI shift has made that cost visible. Before 2022, the cost was absorbed by maintainers who had day jobs and were willing to put in 4 to 6 hours per week. After 2022, the cost is higher and the same people are paying it.
The cost of fixing it is not in dollars. It is in the project structure, the contributor expectations, and the maintainer cap. Projects that have made these changes are reporting sustainable loads. Projects that have not are reporting burnout. The gap is widening.
The migration took about a year of slow process changes for the projects I run. The hardest part was writing the CONTRIBUTING.md that was firm without being hostile. The easiest part was the review rotation, which I had been meaning to do for years.
If you are a maintainer of a small or mid-size project, the changes are worth making. If you are a contributor (human or AI-assisted), the changes affect you too. A good PR with a human summary and a clear intent is welcome. A drive-by PR with no context is a maintainer-time sink, and the AI does not pay that cost.
The biggest thing nobody tells you is that the AI shift is not a single event. It is a slow redistribution of who contributes and how. The projects that survive it are the ones that adapt the maintainer workload, not the ones that try to detect or reject AI contributions. The latter is a losing battle. The former is real work, and it works.