Debian Made The Quiet Problem Loud
On July 24, 2026, Debian opened discussion on a General Resolution about LLM usage in the project. As of July 26, the official Debian vote page lists multiple proposal choices, ranging from forbidding direct LLM-assisted Debian contributions to allowing them with conditions such as accountability, disclosure, licensing checks, privacy limits, and prior discussion for bulk or automated work. That matters because Debian is not a toy repo with three stars and a README written during lunch. It is a major free software project with stability expectations, volunteer maintainers, security responsibilities, and a long memory for process mistakes. The official proposal text is here: Debian General Resolution: LLM usage in Debian.
The broader lesson is not “Debian hates AI” or “Debian has blessed AI.” That would be too neat, and therefore probably wrong. The lesson is that serious projects are being forced to turn AI assistance from a private developer habit into a public contribution policy.
That same pressure is coming for company repos, open source libraries, internal tools, documentation sites, infrastructure scripts, and support macros. If code can arrive with AI assistance, then maintainers need a way to review the work without becoming unpaid forensic archaeologists. The policy has to answer a simple question: what must be true before AI-assisted work is allowed to touch production?
The Problem Is Not AI Use. The Problem Is Unowned Output.
A patch is not safe because a human pasted it. A patch is not unsafe because an AI assistant suggested it. Both positions are lazy, which is impressive given how much energy people spend defending them.
The real problem is unowned output. That is code, documentation, translations, issue comments, configuration, or release notes submitted by someone who cannot explain what changed, why it changed, what it depends on, and what might break. AI just makes unowned output cheaper to generate and easier to dress up in confident prose.
Maintainers already know this shape of problem. It looks like drive-by pull requests that refactor half the project. It looks like dependency bumps with no changelog review. It looks like copied Stack Overflow snippets with license fog. It looks like generated documentation that says plausible things about flags that do not exist. AI did not invent any of this. AI industrialized it.
That is why a useful AI contribution policy should avoid trying to detect whether text “looks AI-generated.” Detection is unreliable, easy to argue about, and socially miserable. Projects need rules based on reviewable facts instead: disclosure, accountability, license review, tests, privacy, and scope.
If a team already uses a checklist for verifying AI-generated technical answers, connect the contribution policy to that workflow instead of inventing a shrine to process. Notavello’s checklist for checking AI-generated technical answers is a good starting point because it focuses on claims, assumptions, tests, and source checks rather than mystical model intent.
A Good Policy Starts With Disclosure That Is Actually Useful
Disclosure should not be a confession booth. It should be a maintenance tool.
Bad disclosure says: “AI was used.” Fine. So was a keyboard. That tells the reviewer almost nothing.
Useful disclosure says what part of the work was assisted, which tool category was used, whether project data was sent to a third-party service, and what the contributor personally verified. It should be short enough that people actually write it and structured enough that maintainers can search for it later.
A practical commit trailer could look like this:
- Assisted-By: AI coding assistant for draft implementation only
- Human-Reviewed: logic, tests, license headers, public API behavior
- Data-Shared: no private issue text, credentials, customer data, or embargoed security information
- Verification: unit tests added; integration test run locally; manual behavior check in staging
For documentation, the disclosure can be even plainer:
- Assisted-By: AI drafting assistant for first-pass wording
- Human-Reviewed: command examples, option names, version behavior, links
- Sources: project docs, release notes, tested local output
The point is not to humiliate contributors. The point is to keep maintainers from asking the same boring questions in every review: Did the contributor understand this? Did the tool see private data? Did anyone check whether the flags compile? Is this copied from somewhere with incompatible licensing? Boring questions are where production incidents like to hide.
The Minimum Receipts For AI-Assisted Contributions
A production-ready AI contribution policy should require receipts in five areas. Not essays. Receipts.
- Ownership: The contributor must be able to explain every meaningful change. If they cannot explain it, they do not own it. If they do not own it, it should not be merged.
- Scope: AI-assisted work should arrive in small, reviewable chunks. A generated thousand-line rewrite is not a contribution. It is a hostage situation with syntax highlighting.
- Verification: The submission must include tests, local run output, screenshots, reproduction notes, or another project-appropriate proof that the change was checked.
- License and provenance: The contributor must verify that copied material, generated snippets, documentation text, and examples are compatible with the project’s license rules.
- Privacy: The contributor must not send secrets, private discussions, unreleased security information, customer data, proprietary source, or internal logs to an unapproved AI service.
Those five requirements are more useful than a giant philosophical statement about whether AI is creativity, autocomplete, theft, statistics, magic, or doom wearing a Patagonia vest. Philosophy can wait. Maintainers have queues.
The policy should also define a higher bar for bulk work. If someone wants to use an AI agent to open 200 pull requests, edit translations across a documentation tree, or file mass issues, require prior discussion. This is not anti-automation. It is pro-not-being-buried-alive-by helpfulness.
Some Work Should Still Be Off Limits
A practical policy can allow AI assistance in some places and ban it in others. That is not hypocrisy. That is risk management.
Low-risk areas may include local brainstorming, test fixture generation, draft comments, typo cleanup, repetitive migrations, or summarizing public documentation for the contributor’s own understanding. Even there, the contributor owns the final result.
Higher-risk areas deserve stricter controls:
- Security fixes: Embargoed reports, exploit details, vulnerability analysis, and private advisories should not be pasted into cloud AI tools unless the project has explicitly approved that environment.
- Legal and licensing files: Copyright notices, license metadata, contributor agreements, and package provenance need human certainty. “The model said Apache-2.0” is not a legal process.
- Public project statements: Release notes, governance messages, and incident updates should be written or deeply reviewed by accountable humans. Tone matters. Accuracy matters more.
- Translations and accessibility text: AI can help, but a fluent reviewer should verify meaning where the text carries user, safety, or legal importance.
- Large refactors: If a change is too large for a human to explain carefully, it is too large to merge comfortably.
The best rule is simple: the more trust a user places in the output, the more human ownership the project should require. AI assistance can be useful. It does not get to launder responsibility.
Make The Policy Enforceable, Or Do Not Bother
The worst AI policy is one that sounds noble and cannot be enforced without paranoia. If maintainers have to inspect every sentence for machine fingerprints, the policy will rot. If contributors have to write a compliance novel for every typo fix, they will ignore it or leave. Either way, the project loses.
Good policies are small, visible, and tied to existing workflow. Add a pull request template. Add commit trailers. Add a “no private data in unapproved AI tools” rule to the security policy. Add a maintainer right to reject AI-assisted bulk submissions that were not discussed first. Add a rule that the submitter must explain the change during review. None of this requires a new priesthood.
A lightweight project policy can fit in one paragraph:
AI-assisted contributions are allowed only when the submitter fully understands and owns the work, discloses significant assistance, verifies the result with appropriate tests or review, respects project licensing requirements, and does not share private or sensitive project data with unapproved AI services. Maintainers may reject AI-assisted submissions that are too large, insufficiently explained, unverifiable, privacy-risky, or submitted in bulk without prior discussion.
That paragraph will not settle the grand debate. Good. It is not supposed to. It gives maintainers a handle. It gives contributors expectations. It turns AI from a shadow practice into a reviewable part of the software supply chain.
That is the practical move now. Not panic. Not blanket trust. Not pretending nobody is using the tools. Put the receipts where the work happens, then make the humans sign their names to the result.