Hey {{first name | there}}. Before this issue begins, I would like to preface this by saying I largely am not against AI/LLMs. I use them daily and think there is a future where we are able to use these tools much better and more efficiently without causing a global RAM shortage.
However, I do think there is a point where we as a collective should assess our approach. Today's issue is in part driven by the distant nightmare that is now the reality of many open source maintainers.
In today's Technical Notes:
Respect people
Read your code
You’re still responsible at the end of the day
📰 TECHNICAL NOTES
To start, I would like to bring you up to speed with the slop attack on open-source;
One of the earliest maintainers to publicly call out the problem was Daniel Stenberg, the creator of curl. He reported that nearly 20% of the security reports submitted through HackerOne appeared to be AI-generated. Most looked convincing at first glance but ultimately described vulnerabilities that didn't exist.
I practically live in Ghostty. The creator, Mitchell Hashimoto, took a different approach. Rather than discouraging AI outright, the project introduced a policy stating that contributors remain responsible for every line of code they submit, regardless of whether it was written by an LLM.
And then we have full bans from larger projects like Zig, NetBSD, GIMP, Gentoo, and qemu reject PRs containing LLM-generated code outright. Zig's is the most philosophical: Loris Cro's April 2026 post "Contributor Poker and Zig's AI Ban" argues maintainers bet on a contributor's long-term potential, not individual PRs.
Why I think this is dangerous
Long-term, I think yeeting PRs at maintainers will do more harm to open-source than good. This is because for the longest time, open-source has been built on trust and the good will of maintainers who work many times uncompensated.
Now, do I think the answer is to “give maintainers more tokens”? No, as the contributions themselves aren’t the problem but the lack of process and thought surrounding it. I like to point to the Kubernetes project as a good example.
Kubernetes can consistently deliver releases that serve thousands because of the surrounding release process by maintainers and special interest groups. If you were to take the average “vibecoded” pull request, you’d be rolling the dice with 3 sides being:
Possibility of malware/vulnerability being injected
Singular feature request that suits the sole interest of the contributor
Resolving an issue that quite literally does not exist
Ultimately, I think this goes back to the collective responsibility we have when thinking about contributing to open-source projects. While LLMs have the ability to change how much we can get done, I’d argue it was never about merging singular contributions but how changes affect the project as a whole.
🌍IN THE ECOSYSTEM
The week wasn’t all gloom; here are some interesting reads from last week:
Who does this actually stop?: Anubis is a project aimed at preventing bots and agents from retrieving content from a web page via a proof-of-work system. This blog explores the idea of who this actually stops because agents can bypass this now.
Homelab Overhaul: If you’ve followed for long enough, you’d know I love a good homelab blog or resource, Tim Hårek shares some major changes to his homelab.
Anubis: If you’re curious about what the project is, here is a talk by the Author
The Zig drama was funny to watch
⏱️UNTIL NEXT TIME
The conversation around AI often focuses on productivity. How much faster can we write code? How many more issues can we close? How many more pull requests can we open?
Maintainers trust that contributors have taken the time to understand the code they're submitting. Contributors trust that maintainers will review their work fairly. That relationship is what has allowed some of the world's most important software to be built by people who, in many cases, have never met.
As contributors, we still own the final draft. And if we want open source to remain healthy, that's a responsibility we can't outsource.
Share this link with an engineer who would find it helpful.
Jubril Oyetunji
CTO, EverythingDevOps
