Debian is polling its developers on how to handle AI-assisted contributions, with options that range from broadly permitting them to banning them outright. Whatever the outcome, I think this is one of the more consequential governance conversations in open source right now, and not for the reason the headlines suggest.
The framing everyone reaches for is philosophical. Is generated code authored? Is it derivative? Does using a model make you less of a contributor? Those are real questions and I do not have confident answers to them.
But if I imagine actually being a Debian maintainer, my problem is not philosophical at all. It is that my queue is full and my reviewing hours are finite.
The bottleneck was never writing code
Volunteer projects have always been constrained by review capacity, not by supply of patches. The scarce resource is someone knowledgeable enough to say "this is correct, this fits our conventions, I will own the consequences if it breaks."
Assistants change the ratio between those two things dramatically. The cost of producing a plausible patch has fallen much faster than the cost of evaluating one. That asymmetry is the whole story. A project can absorb a lot of contributors when each contributor's output is roughly proportional to their understanding. It struggles when someone can submit a large, fluent, superficially reasonable change to a subsystem they have never read.
I want to be careful here: plenty of experienced maintainers use these tools well, and their patches are better for it. The failure mode is not the tool. It is the decoupling of confidence from comprehension.
Why detection is the wrong axis
A ban sounds like a clean answer, and I understand the appeal. But I am skeptical it can be enforced in a way that means anything.
You cannot reliably detect generated code, especially after a human has edited it, and especially for the kind of small idiomatic patch that makes up most of a distribution's traffic. A rule you cannot enforce does not produce compliance. It produces silence: people stop disclosing, which is strictly worse than a norm that encourages honesty.
So the more useful axis is accountability rather than provenance. Not "did a machine help you write this," but "do you understand this well enough to defend it, and are you the one who will be here when it breaks?"
That shifts the question to things a project can actually check. Can the contributor explain why this approach and not the obvious alternative? Did they test it on real hardware or just assert that they did? Is the changelog honest about scope? Have they engaged with review feedback in a way that shows they read the code?
Those signals have always separated good contributors from noisy ones. They just matter more now, because fluency no longer implies effort.
Disclosure as a courtesy, not a confession
I have come around to thinking that disclosure norms are worth having anyway, even though they are unenforceable, because of what they do culturally rather than technically.
If saying "I used an assistant for the boilerplate here, and I verified the parsing logic by hand" is normal and unremarkable, reviewers get useful information about where to focus. If it is treated as an admission of laziness, nobody says it, and reviewers get nothing.
The projects I expect to handle this well are the ones that write down what they want from a contribution rather than what they forbid. Something closer to: you are responsible for every line you submit, you must be able to explain it, large changes need prior discussion, and tests are not optional. None of that mentions AI. All of it addresses the actual risk.
What is really being decided
A distribution like Debian is infrastructure for a staggering amount of the world's computing, maintained largely by people doing it in their spare time. Its trust model is social: humans vouching for humans, over decades, with reputations that took years to build.
The question on the table is not really about tooling policy. It is whether that social fabric can survive a sharp increase in the volume of plausible contributions from people with no accumulated stake in it.
I do not know the answer. I do know that a permit-or-ban vote is a blunt instrument for a problem that is fundamentally about attention and accountability. Whatever the ballot says, the projects that come out healthy will be the ones that got explicit about what a maintainer owes the code and what a contributor owes the maintainer.
That conversation was overdue regardless of the machines.
Top comments (0)