Skip to main content

Cheap Patches, Expensive Reviews: What Debian's LLM Resolution Is Actually Asking

· 7 min read
Isaac Zhao
AI Coding Club Creator

I opened the HN thread expecting a tidy summary. The submission title said "LLM Usage in Debian: Three Proposals." When I clicked through to the official Debian General Resolution page, it listed four.

That gap — three on the aggregator, four on the source — is a small thing, but it caught my attention in the way small things do when a governance process is still moving. The page showed a status of In Discussion and a discussion-period date of 2026-07-24. Nobody has voted. Nothing is decided. The community is working through something genuinely hard, and the working copy keeps changing under everyone's feet.

The resolution is titled General Resolution: LLM usage in Debian. As of 27 July 2026, four proposals — A through D — are visible on the official page. That count may not be final, and none of these proposals has won.

Summarizing them without collapsing their real differences:

Proposal A wants to prohibit direct Debian contributions that were written with LLM or generative-AI assistance. The scope is explicit: it targets Debian-specific work, not upstream projects or upstream patches and security fixes.

Proposal B takes the opposite stance. It would allow partially or fully AI-assisted contributions under a set of conditions — legal compatibility, licensing and attribution, contributor accountability, disclosure requirements, rules around bulk automation, and protection of confidential or non-public data.

Proposal C lands between those poles. It asks contributors to avoid LLMs as far as practical, requires that contributor messages be human-drafted, mandates disclosure, and importantly, gives individual projects or maintainers the authority to ban LLM contributions outright within their own domains.

Proposal D accepts AI-assisted work on Debian-specific tasks while making the accountability question explicit. A contributor using AI assistance must still understand the work, be prepared to defend it, explicitly submit production-bound content themselves, mark it appropriately, ensure DFSG compliance, and protect any sensitive or non-public data.

The HN thread had 209 points and 208 comments when I checked on 27 July 2026. That kind of comment volume tells you this touches something raw. The opinions in the thread are not policy evidence, and I won't treat them as such. But the fact that people on a developer forum are debating the specific shape of accountability — not whether AI is good or bad, but who owns what after the diff lands — feels like the right question surfacing at the right time.

I use coding agents in real work. Most days they're useful. An agent returns a patch, and my first move is to read the diff — not skim it, read it. Then I run the tests, if the project has them worth running. Then I decide whether I'm willing to stand behind what I'm about to submit. That process takes time and attention. Some patches I send. Some I throw away after reading, because the agent produced something plausible-looking that would have caused a mess downstream.

That sequence matters more than the generation step. AI can generate a patch; it cannot sign for the consequences.

This is what Debian's debate is really about, whether or not that phrase appears anywhere in the proposals. Generating a plausible patch has become cheap. Understanding it, testing it, and being accountable for it after merge has not gotten any cheaper. If anything, the gap between those two costs is growing — because the generation side is accelerating faster than the review side can absorb.

When a contributor submits a change they cannot explain, the cost doesn't disappear. It moves. It lands on the maintainer, who is often a volunteer, often with too many open issues already, and who now has to do the intellectual work the submitter offloaded to a language model. They have to figure out what the change is actually doing, whether it interacts badly with anything else, and whether the person who submitted it can answer questions if something breaks in six months.

I have a lot of sympathy for that position. The open-source maintenance burden was already a serious problem before AI tools started making it faster to file issues and generate contributions. A regime where submissions double while submitter understanding stays flat is not a better regime — it is a cost-transfer mechanism dressed up as productivity.

Proposal D's language about "understanding and defending the work" is not bureaucratic fussiness. It is a functional requirement for the downstream humans who have to live with what gets merged.

That said, I understand why some projects or maintainers might want the cleaner boundary that Proposal A represents. The accountability argument I am making above assumes the contributor actually does the work of understanding before submitting. Not everyone will. The AI-generated contribution that arrives with full disclosure and zero comprehension is not much better than the undisclosed one. Proposal C's approach — allow projects to set stricter rules — acknowledges this honestly: different contexts have different risk tolerances, different maintainer capacities, and different community cultures. A one-size resolution may not serve them all.

There are also reasons beyond workload. Proposal A raises legal uncertainty around AI-generated code. Some communities have ethical objections to how large language models are trained. Some maintainers simply do not want to deal with the uncertainty, and that is a legitimate position to take, not a technophobic one.

What I keep coming back to is this: the cheaper patch generation gets, the more weight falls on the human who presses submit.

Disclosure matters because it lets reviewers calibrate their questions. Accountability matters because it creates a reason for the submitter to actually read the diff before filing it. The ability to defend the work matters because software does not stop existing after merge — it gets maintained, modified, blamed when things break. A contributor who cannot explain the change they submitted is not really a contributor to the long-term work; they are an intermediary who handed off generated text and walked away.

Open-source contribution has always depended on a chain of responsibility. Someone wrote it, someone understands it, someone can be asked about it. AI tools can extend what a single person can produce in a day. They do not extend that chain. They can shorten it or break it, depending on how they are used.

Debian has not resolved this. As of 27 July, the resolution is still in discussion. I do not know how the vote will go, and I am not going to predict it. What I think is true regardless of the outcome: the projects that come through this period well will be the ones that kept the human accountability loop intact, whatever technical tools their contributors used to get there.

Sources