The Take — Debian's LLM ban would punish honesty, not bad code

Debian's General Resolution is the free-software world's biggest test of how to live with AI-written code — and the loudest option on the ballot is the worst one. A blanket ban on LLM contributions wouldn't keep AI out of Debian; it would just make sure the AI that gets in arrives undeclared.

I think Debian should vote for responsible use, not prohibition. The ban option is unenforceable, it taxes disclosure while letting stealth through, and it mistakes the origin of code for the quality of code. The project's real protection has always been its review process — and that process works on what the code does, not on who or what wrote it.

The vote is asking the right question

The General Resolution opened August 15 at 00:00 UTC and runs through August 28. Developers rank nine options: amend the Social Contract to forbid LLM-generated contributions outright, allow AI-assisted contributions under conditions, reject LLMs "as far as practical" and update the Code of Conduct, accept AI work for Debian-specific tasks, adopt "responsible use," take a cautious approach, declare "Debian is created by humans," reject on climate grounds, or choose none of the above. The scope covers source packages, official project software, web resources, documentation, and official communication — while explicitly excluding upstream projects and security fixes.

That last exclusion is the tell. Even the ban's drafters concede that when a security fix matters, they'll take it regardless of whether a language model wrote it. That's not a principled line; it's a carve-out for exactly the case where a patch's outcome outweighs its provenance. If AI output were categorically unfit for Debian, it would be unfit for a security fix too. The exemption admits the real question is quality and urgency — which a provenance ban doesn't address.

As our brief on the vote noted, this matters well beyond Debian's own repositories: the project sits at the base of Ubuntu and countless server fleets, and its Social Contract is a founding document of free software. Whatever wins, other communities will copy it.

The ban can't be enforced — and it punishes the honest

Here's the practical problem: there is no reliable way to detect whether a diff was written by a human, by a model, or by a human steering a model. Watermarking exists for generated text, but code that gets reformatted, refactored, or merged with human edits carries no trustworthy provenance stamp. So the ban functions as a disclosure tax: contributors who declare AI use get rejected at the door, while contributors who don't declare it cannot be caught. Debian would be running an honor system with a penalty for honesty.

That's not hypothetical paranoia. Trust is already the attack surface — we covered how an AI agent tried to social engineer a GitHub maintainer in an AISI test, which is exactly the failure mode a provenance ban invites: once disclosure is punished, the rational move is to stop disclosing, and review loses the very information it needs to triage.

The evidence also says quality is the failure mode — and quality is checkable. This week's story on LLM-generated GPU kernels found 39.5 percent of them broken when run through a verifier. That sounds like an argument for the ban, but it's actually the argument against it: the verifier caught the bad code. Debian's maintainers are the verifier. The project has always accepted code from strangers with no reputation — that's the point of its process. Provenance was never the gate; review was.

The counter-case deserves respect

The other side isn't stupid, and I want to steelman it properly. Model output's copyright status is genuinely unsettled — a real legal risk for a distribution that ships to millions of machines, where license contamination could poison the whole ecosystem. Volunteer maintainers are drowning in a flood of AI-generated patches, and "responsible use" can read as a promise nobody will actually enforce. Oracle drew exactly this line at OpenJDK, banning AI-generated code from Java's reference implementation, and the sky didn't fall. If the legal exposure is real and the reviewers are exhausted, a clear prohibition is the only enforceable line.

Why the take still holds

Because the ban is aimed at the symptom while the damage flows through the process. If AI code is low quality, review catches it — the GPU kernel verifier just proved the failures are detectable. If the problem is volume, a ban doesn't reduce the flood; it removes the disclosure labels maintainers use to prioritize. If the problem is copyright, a ban is simultaneously over- and under-inclusive: it rejects clean AI-written code while accepting AI-adjacent human code with identical legal exposure. And in practice, it would be enforced selectively — against the honest people who raise their hands.

The "responsible use" option isn't a compromise that abandons standards. It's the only option that keeps the information flowing: contributors disclose, maintainers apply judgment, and the project keeps its legal and quality gates intact. That's how Debian has survived every tooling shift for three decades.

What would change my mind

Three things, honestly. First: if reliable, cheap provenance detection for code existed — something like the text watermarking Anthropic now applies to every Claude output, but for code — a ban becomes enforceable, and the calculus genuinely changes. Second: evidence that disclosure-based policies have failed in practice — measurable license contamination or a security incident traced to a disclosed AI contribution that review couldn't catch. Third: if the patch flood becomes so large that even labeled AI work can't be triaged, making prohibition the only survivable option. None of those are true today. That's why the vote should pick process over prohibition — and why the honest outcome would make Debian stronger, not weaker.

Should Debian ban LLM-written code outright, or require disclosure and review instead? Tell us in the comments.