4 min read
In short
A ban on AI-generated code seems like a simple way to protect projects, but in practice, it’s difficult to define and rarely enforced. It’s much more useful to shift the responsibility to the patch author: to disclose the use of AI, demonstrate an understanding of the changes, and not pass the cost of verification on to the maintainers.
The “AI-free” label promises trust but does not prove quality. For open source, this is a dangerous shift: instead of verifying what the code does, the community begins to verify how it was produced.
The problem isn’t that generative models have suddenly become reliable. They can indeed produce vulnerable code, make mistakes with licenses, reproduce fragments of training data, and generate patches that look convincing only until the first run. But human authorship, in and of itself, has never guaranteed security, maintainability, or legal compliance.
A repository stores code, not proof of the author’s virtue.
The ban quickly runs into a gray area
What counts as AI-generated code? A function written entirely based on a prompt? A line from autocomplete? Automatic refactoring? A test generated from an existing implementation? A hint for an unfamiliar API, after which the developer wrote everything by hand?
The line is already blurred, and AI features will become even more deeply integrated into IDEs, debuggers, search engines, and other tools. As a result, an honest developer who disclosed the use of the model may end up in a worse position than someone who simply kept quiet. And the project will be labeled with a tag that cannot be reliably verified.
This looks particularly strange to a community accustomed to viewing unverifiable claims with suspicion. “AI-free” is exactly that kind of claim.
The Real Problem Isn’t Generation, but the Cost of Review
AI has an unfortunate asymmetry: creating a patch is getting cheaper, but verifying it is not. An author can churn out thousands of lines in minutes and send them to a volunteer, who then has to spend hours reconstructing the context, hunting for errors, and figuring out whether the author even understands their own solution.
This is practically a denial-of-service attack on maintainers. But the solution doesn’t necessarily lie in banning the tool. It makes more sense to shift the cost and responsibility back to the person submitting the changes.
A practical project policy might require the author to:
- disclose any significant use of generative AI in the commit message or pull request;
- name the tool and describe exactly how it was used;
- confirm that the author understands and can explain the entire patch;
- include targeted tests and explain what real problem the change solves;
- comply with licensing and code provenance requirements;
- keep changes small enough for a reasonable review;
- accept that massive, unexplained, and insubstantial patches may be rejected without detailed scrutiny.
This does not automatically make AI-generated code good. It does, however, make the rules verifiable. What matters is not the ritual of requiring every token to be written by a human, but the ability of a specific author to take responsibility for the result.
Where Restrictions Are Still Appropriate
Projects have very specific reasons for restricting AI tools. You must not send secrets, private messages, details of an undisclosed vulnerability, or other sensitive material to unauthorized external services. Critical components may require stricter requirements regarding the origin of changes. Maintainers also have the right to reject a stream of automatically generated reports if it consistently creates noise.
But these are restrictions tied to risk, not to the moral status of the tool. They protect the privacy, security, and time of reviewers. A blanket ban simply declares the development method itself to be a problem and leaves the main question unanswered: did the code pass verification?
Such a ban also comes at a cost. It may deter new participants—people for whom AI has become a tool for accessibility—and developers working in a language other than their native one. It also precludes useful scenarios—explaining legacy code, writing tests, documentation, cross-platform porting, and automated modernization. The model cannot reliably perform this work on its own, but it can assist a human who is capable of verifying the result.
Free software is not obligated to preserve old development rituals for the sake of the rituals themselves. High-level languages, IDEs, code generators, formatters, static analysis, and online search have already blurred the line between the work of a programmer and that of a machine. The criterion has remained not the purity of each character’s origin, but human control over the system.
Therefore, a reasonable stance for open source seems quite strict: AI should not be trusted, but it should not be banned entirely either. We must demand transparency, understanding, testing, and licensing clarity, and we must protect the limited resources of maintainers.
A bad patch should be rejected regardless of whether it was written by Claude, Copilot, Stack Overflow, a contractor, or a person having a bad day. And “AI-free” should be viewed not as a seal of quality, but as a warning: the project is currently selling the code’s origin rather than evidence of its suitability.