The vote is open. After a phase of collecting proposals, Debian developers have started the general resolution process to decide how to treat LLM-generated contributions within the project. This is not a matter of technological preference: it is a choice about who guarantees the code that ends up in one of the most widely used distributions in the world, including on servers and in on-premise deployments.

Anyone following AI-RADAR knows that the model is only part of the problem. The often overlooked issue concerns the code and processes that feed inference and fine-tuning pipelines. An LLM can produce formally correct patches that are opaque in origin: there is no author with legal responsibility, training data may include code with incompatible licenses, and human review becomes more burdensome, not less.

The thesis emerging from this vote is that Debian is turning a technical question into a structural signal: the cost of trust in software rises when automation enters the code production chain. If the project takes a restrictive position, maintainers protect traceability at the expense of speed; if it takes a permissive position, it shifts risk onto auditors and release managers. Neither path eliminates the underlying problem: an LLM is not a contributor with identity, it is a statistical surface.

The stakes beyond a single patch

The second-order consequence concerns maintainers. An LLM-generated contribution may look reasonable in a diff but can hide subtle vulnerabilities or undocumented behavior. In distributions used as the base for self-hosted servers, this translates into extra burden for those who must maintain reproducible and signed builds. The third-order consequence affects companies: if Debian restricts LLM use, vendors integrating its packages can claim a more controlled supply chain but lose a potential automation channel; if it opens up, they gain speed but must strengthen compliance checks.

For those evaluating on-premise and self-hosted deployments, the trade-off is not new. AI-RADAR offers analytical frameworks at /llm-onpremise to compare the costs of control and automation, but Debian's decision adds a governance precedent that few other projects can afford to ignore. This is not about blocking or accepting a tool: it is about establishing who is accountable when an LLM-generated patch becomes a production issue.

Whatever the outcome, the vote will not close the debate. It will only indicate where a technical community decides to draw the line between acceleration and control. For this reason, the Debian resolution should be read as a proxy: it measures the tolerance of an open source infrastructure toward a type of automation that does not sign, does not explain, and does not answer.