Why agentic coding changes everything for the open-source craft and maintainership.

It has been two months since I’ve been using AI coding agents “for real”. In my previous article, I reflected on my experiment to vibe-code a full Emacs module from scratch. In there, I intentionally left one important question unanswered: what is the meaning and impact of agentic coding on the free software ecosystem we have all grown accustomed to?

Right now, I have many thoughts but no good answers, and the reason is that the more I use these tools, the more I doubt my long-held beliefs about open-source licensing. While I’ve found that agentic coding makes me more productive—provided I supervise the agents carefully, in some circumstances—it also distances me from the act of coding itself, stripping away the pride of craftsmanship and thus the desire to publish code as open source.

The bigger worry, however, is for the ecosystem as a whole. Let’s dive into what’s on my mind right now.

A little history

I’ve been into open source for almost 30 years now. My first exposure to the ecosystem was the FIPS utility, which I had to use to install my first Linux distribution (Caldera OpenLinux 1.1 if you are wondering). To young-me, a 13-year old interested in low-level software and having only been exposed to Windows and OS/2, having full access to the source code of a frigging disk manipulation tool and even a full OS was mind-blowing.

From that moment on, I took the GPLv2 to heart because access to this ecosystem, vast in size and completely free, felt like a gift. I started publishing my own code as free software, licensed under the GPLv2, and I quickly got involved into existing projects. Not too long after, I joined NetBSD “full-time” because I found in it the perfect balance of “a system that worked well-enough for my day-to-day needs but that had plenty of room for contributions”.

As I continued to encroach myself in the BSD ecosystem, I was exposed to many… “discussions” comparing the GPL against BSD-like licenses. I came out believing that the GPL was more restrictive than the BSD licenses because it imposed extra limitations on consumers. As outreach was the (my) goal, I was all-in on licensing my code via BSD-like licenses. Until maybe now.

Friction no more

If you ask a modern AI agent to work within the constraints of an established project, you will realize that the agent’s output follows the architecture and coding style of the project extremely closely. The diffs I get back are really similar to what I’d have written by hand. But… even if you don’t prompt the right way, you still get features that work. Slop, probably, but still functional. And that’s what’s rubbing me the wrong way with regards to open source licensing.

In the past, when you published a piece of free software, you knew there was some risk that someone could take your code and selfishly benefit from it. But, for the most part, taking a project and modifying it in a way that provided value to users required significant effort. If someone wanted to build on your project and then redistribute it, they had to spend the time to change it and they had to reason about the consequences of their changes, the project’s license, and their own long-term maintenance efforts.

With AI? All of that seems gone. It’s just too easy for anyone to pick an existing project, run it through an agent to customize, fork, and ship it out. Zero need for any real time investment. Zero consideration for what was there in the first place. Zero need to worry about future maintenance because agents will just pile onto whatever they did before and, to users, it will all seem to work.

So, here I am, starting to question my long-held thoughts on copyleft licenses. As I said above in my personal story, I grew up believing that BSD licenses were the better choice for true software freedom. But now? Is it really a good idea to ship BSD-like licensed code anymore? The chances of a slop fork happening are way too real, and the consequences dire: after all, said fork will be able to display tons more features with ease, gain traction, and the pressure against upstream to “do something about them, quickly!” will be a thing. Left unattended, any interest and community around the original project may vanish.

And the reason I’m writing this article is because there is this disturbing thought in my mind right now: should I flip 180 degrees and start licensing my future code as… no less than the “evil” AGPLv3? I have usually avoided this license, but it sounds like it is the only chance at protecting projects from slop (commercial) forks.

Contribution doubts

But then what? Suppose you publish your project as AGPLv3. Suppose a downstream consumer forks the project and starts building on top of it with immense velocity thanks to AI agents. And suppose they have no problem with keeping the project open source per the license. Their changes may be slop, but they may be delivering features that users have wanted for a long time—and let’s face it, the vast majority of people have little consideration for software quality or performance.

In this situation, as the upstream, what do you do? Do you try to incorporate the vibe-coded changes with the massive effort that this requires? Or do you ignore them and hope that they go away, collapsing under their own complexity weight? The truth, I suspect, is that they won’t go away, so you as upstream may become irrelevant very quickly unless you can keep up with the “contributions” being made. Whether you care or not depends on why you published your code as free software in the first place, and different authors have different motivations.

So what else can you do? Maybe you make the project’s test suites proprietary and keep them secret. In an AI-powered world, test suites are THE secret sauce to keep agents on track, so if you don’t publish yours, slop forks will have a hard(er) time staying aligned with upstream. Unfortunately, keeping test suites secret is logistically difficult and annoying, plus it goes against the very tenets of a free software project.

No easy choices here…

What do you think?

I have several more thoughts on the topic of AI and how it affects open source, particularly regarding contributions and the feeling that they can easily lead to burnout, but in this article I wanted to focus purely on the licensing choices. I want to close this not with answers, but with a recap of the questions that would be nice to discuss:

• If AI can closely mimic your architecture with zero effort, does the “friction of modification” need to be replaced by the legal friction of the AGPL?

• Is keeping test suites proprietary a legitimate “moat” for human maintainers, or does it violate the core spirit of open source?

• If we accept that AI agents are a tool and that, properly guided, can produce good PRs at an overwhelming rate, how do we keep up with contributions?

• If you end up vibe-coding most of a project, does it even make sense to open-source it? Why? What pride is there in that?

Share your thoughts in the comments section!