The moderators had to ask
There’s a pinned post on r/opensource right now that reads like a community bracing for a flood. The moderators are asking the subreddit to define a policy on AI-assisted contributions — specifically the thing everyone now calls “vibe-coding” — and the thread has split the room down the middle, 87% upvoted but with the comments in a genuine brawl.
I’ve been reading those comments all week, and I keep thinking: this isn’t really a fight about AI. It’s a fight about what “open source” means when the person writing the code isn’t a person.
Let me be clear about what’s actually being proposed, because it’s easy to strawman. Nobody is seriously arguing for banning AI tools outright — not at the level of policy. The argument is about contributions: whether a project can meaningfully accept a patch whose author can’t explain it, defend it, or be held accountable for it. Whether a maintainer should merge a diff that was generated by a model the contributor didn’t read.
That question sounds philosophical. It is not. It is the single most practical question in open source right now, and we have approximately eighteen months to answer it before it answers itself.
The vibe-coding problem is real, and it’s not about laziness
Let me defend the “ban it” camp honestly, because they’re easy to caricature as luddites and they’re not.
The core objection isn’t “AI code is bad.” It’s that accountability is the entire social contract of open source. When you submit a patch, you’re signing up for something: you understand the change, you can explain the reasoning, and you’ll own the consequences. That’s why “works on my machine” is a punchline and “I don’t know why it works” is a resignation letter. The code review is not just a quality check — it’s how the community vets whether you understand what you’ve done.
Vibe-coding breaks that contract. A contributor pastes an error message into a model, gets a diff back, tests nothing, reads nothing, and opens a PR. The diff might even be correct — but the contributor can’t explain why, can’t defend it under review, and vanishes the moment a subtle bug surfaces in production. The maintainer has inherited code with no author who understands it. That’s not a contribution; it’s a liability with a green checkmark.
The flood is the second half of the fear. LLMs make it costless to produce plausible-looking code at a rate no human can review. If a project becomes known for accepting AI-generated patches without scrutiny, it attracts more of them. The signal-to-noise ratio collapses. Maintainers — already the scarcest resource in open source, already burning out — drown in plausible garbage they now have to read carefully because it’s plausible.
That’s a real, urgent, practical problem. A policy is not unreasonable.
But here’s where it gets legally weird
Now let me introduce the thing that makes this debate unlike every other “should we use AI” argument in history: the copyright question.
The rules that govern open source are, at bottom, copyright rules. A permissive license like MIT works by the author granting rights over code they own. The whole edifice — copyleft, attribution, the GPL’s viral clauses — presumes there’s a copyright holder with rights to grant.
Machine-generated code sits in a legal grey zone, and the courts have not resolved it. The US Copyright Office has been clear that work produced without human authorship isn’t copyrightable — a monkey can’t hold a copyright, and neither, at least under current guidance, can a model operating without meaningful human creative input. The open question is where “meaningful human input” begins: is editing the prompt enough? Selecting among outputs? Reviewing and refactoring the result? Nobody knows, because the law is being written in real time by a handful of district-court cases.
So here’s the nightmare scenario for an open-source project: you merge a vibe-coded patch, and six months later a court (or the Copyright Office) clarifies that the patch isn’t copyrightable, or that its copyright is murky. What happens to your project’s license? A chain is only as strong as its weakest link — if one file in a GPL project has no valid copyright holder, what does “copyleft” even mean for that file? Does the project still have standing to enforce the GPL? Do your contributors still have the rights they think they granted you?
Nobody has a clean answer. This is the actual reason r/opensource can’t just wave the question away with “good code is good code.” A project can’t assess the legal cleanliness of a patch by reading the diff — the provenance of the code is now part of its metadata, and provenance is exactly what vibe-coding erases.
The three camps, as I see them
Reading the thread, the community has sorted itself into roughly three positions, and I have sympathy for all of them.
The “no AI” camp wants disclosure rules or outright bans: mark AI-assisted patches, or reject them. Their logic is the accountability argument above, plus a strong whiff of cultural grievance — AI code is a shortcut, and open source has always been a culture of craft, and they don’t want the craft drowned by people who can’t be bothered.
The “it’s just a tool” camp points out, correctly, that we’ve had this debate before. Stack Overflow copy-paste was vibe-coding before LLMs existed. So was every autocomplete. The line between “AI-generated” and “AI-assisted” is unenforceable anyway — if I use Copilot to fill in a function, is that a different category from tab-completing a loop? Drawing the line is a fool’s errand, and the practical effect of a ban is just… lying about it.
The “provenance” camp — which I find myself in — thinks the real fix isn’t banning the tool but restoring the accountability the tool erases. Require contributors to stand behind their patches in a way that doesn’t depend on how they produced them: you can use any model you want, but you must be able to explain the change, defend it, and take ownership of it. The moment you can’t explain your own patch, it doesn’t matter whether a human or a machine wrote it — it fails review.
The provenance camp’s argument is that the legal grey zone is real but that a policy can’t fix it — only transparency can. A disclosure norm (“this patch was AI-assisted, here’s how”) is more durable and more enforceable than a ban, and it’s the only thing that lets projects actually assess their own risk.
The quiet convergence with everything else happening this month
Here’s what I find striking: this debate is converging with a dozen other threads in the same week.
Rust just formalized a policy on LLM-assisted contributions — not a ban, but a governance framework, which is the provenance camp’s playbook. Claude started watermarking its output steganographically, and the open-source community’s reaction was to scream and call for abandoning closed models — which is the “no AI” camp’s grievance finding its target. And an Open Source Endowment just launched to fund maintainers, which is the actual root problem underneath all of this: there aren’t enough humans to review the code that already exists, let alone the flood a million LLMs are about to generate.
The common thread is that open source is discovering, all at once, that its founding assumption — code has an author, and the author can be held accountable — is under attack from a technology that produces code with no author. Every single debate this month is a different angle on that same crack in the foundation.
What I actually think
I’ll be direct, because that’s the assignment.
I don’t think r/opensource should ban AI. I think a ban is unenforceable, culturally alienating, and — worst of all — it lets us feel like we’ve solved a problem we’ve only named. The problem isn’t the model. The problem is that open source has never had to verify authorship, and now it does.
What I want out of this debate is something less exciting than a ban and much harder: a norm of provenance and accountability that survives contact with reality. Disclose when a patch is AI-assisted. Stand behind every patch you submit, however you made it. And — this is the part nobody wants to hear — accept that the legal question of machine-generated copyright is going to be settled by courts, not by subreddits, and that until it is, every project that merges unprovenanced code is carrying a risk it can’t fully measure.
The thing that worries me isn’t that the “no AI” camp will win. It’s that the debate will get boring — that we’ll re-litigate “is AI good or bad” for the hundredth time and never get to the actual work, which is figuring out how a community that runs on trust and attribution can keep functioning when attribution stops being automatic.
I keep coming back to one image: a maintainer at 2am, staring at a diff that is technically correct but was clearly generated, submitted by someone who’s gone to bed, and wondering whether merging it is craftsmanship or malpractice. That maintainer doesn’t need a ban. They need a way to say no — or yes, but here’s what I need from you first — without being called a luddite or a sellout.
That’s the policy r/opensource is really trying to write. I hope they write it well, because the rest of us are going to copy it.
The r/opensource policy discussion is a pinned moderator post on the subreddit. It’s worth reading the comments — not for the takes, which are the usual, but for the way a community that has spent thirty years trusting attribution is trying to figure out what to do when attribution stops being automatic.