freenode
AnalysisLanguages & Toolchains

Projects draw hard lines as AI contributions eat reviewer time

LLVM, the kernel, and Emacs are fighting the same battle: how to protect scarce maintainer attention without shutting out legitimate help.

Reviewer bandwidth is the scarce resource, and AI-assisted contributions are colliding with it at scale. Across LLVM, the Linux kernel, and Emacs packaging, the same fight has broken into the open: how to stop extractive, low-effort submissions from burning out maintainers without slamming the door on people who use tools carefully and take real responsibility for the result.

The pressure is not abstract. Nikic’s LLVM RFC would leave the project’s liberal stance on AI-written code mostly intact, while banning “AI-generated or substantially AI-assisted textual communication,” including pull request descriptions and RFC texts. The stated target is not tooling in general but a flood of verbose, low-quality PR writeups, especially from new contributors, packed with routine testing noise and gratuitous formatting. Those descriptions, nikic argues, are “a drain on our limited reviewer bandwidth,” both because they take longer to read and because they need heavy rewriting before anything can merge. More sharply, auto-generated prose skips a sanity check that the “human in the loop” model depends on: the contributor understanding the change enough to say what it does in their own words.

That concern is shared. Rengolin puts the fairness point bluntly: asking a third party to write the description “offload[s] the understanding to the tool and push[es] the onus of proof onto reviewers,” which is “unfair to reviewers and is already provably pushing reviewers away.” Chandler Carruth goes further on process culture. His preferred posture is closer to chat moderation than endless mentoring: “delete and ban quickly to preserve the quality of the community,” because “we can’t welcome spam sustainably,” even if that feels less welcoming. Shafik and others note that review bandwidth was already thin before LLMs; the tools simply hit the weakest point harder. Maintainers often already know who submits extractive work; they have lacked a clear mandate to act.

Pushback inside the LLVM thread is not a defense of spam so much as a warning about blurry lines and false positives. Chandler himself describes a disciplined workflow: strict instructions to an LLM about how LLVM writes commit messages, then ruthless human editing for brevity. Void and others ask who arbitrates “AI slop” when a carefully written message still uses a semicolon or an em dash that some readers treat as a tell. Jrtc27’s counter is partly technical and partly social. Even a perfect harness that mimics a developer’s voice does not erase the etiquette problem: shipping machine prose for other humans to spend scarce time on, without doing equivalent work yourself, “is just rude.” Writing the message forces engagement with the actual diff. Enforcement, nikic-aligned voices argue, can look like other trust rules: there is no foolproof detector for lifted copyrighted code either, yet the project still states norms and can act when patterns are clear.

The kernel is having a parallel argument with different paperwork. A Maintainers Summit consensus, carried by Sasha Levin’s patch, deprecates the Assisted-by tag and strips it from the coding-assistants and submitting-patches docs and from checkpatch. Attribution theater is being abandoned; the submitter’s Signed-off-by and full responsibility remain the load-bearing requirement. The surrounding list traffic is less about the tag’s wording than about patch floods and burnout. Theodore Ts’o frames the ugly choice directly: faced with a surge of newcomer patches, the options are load-shed or burn out, and load-shedding is the better of two bad choices. Lyude and others push back on the instinct to automate more of review with non-deterministic tooling while under-investing in maintainer capacity. Linus Torvalds dismisses “determinism” as a “total red herring” and a strawman for dislike of AI, noting that non-deterministic and version-skewed tools are not new in the toolchain. The unresolved kernel question is not whether a tag exists, but how maintainers triage volume, what “human responsible for the contribution” means when models draft large chunks, and how much process should be spent on provenance versus on whether the patch is correct and worth the review cost.

Emacs shows the same tension at the packaging boundary. Lucius Chen asked to put Clutch, an interactive database client, on NonGNU ELPA, disclosing OpenAI Codex and Claude Code use via Assisted-by headers, and sought a clear provenance ruling before investing further. Eli Zaretskii’s practical answer is that NonGNU ELPA packages are exempt from the stricter GNU LLM-code policy the way they are exempt from FSF copyright assignment: a free license matters; LLM-free preference is softer there. Richard Stallman still draws a hard line for GNU packages proper, citing possible legal trouble if copyleft cannot be enforced on code with “no human author,” and wants LLM-generated regions recorded even when immediate deletion is not required. Johan Myréen and others complain that policy lived mainly in ad hoc “did you use AI?” mail, so contributors learn the rule after hundreds of hours. Stallman drafted CONTRIBUTE text and pressed for finer distinctions: automated error checking is harmless; “initial draft then rewrite” may still leave a derivative of model output; “code completion” needs concrete examples. Transparency can look like a penalty when silent use slips through, which is exactly the detection problem LLVM debaters fear.

Threaded together, the three fights are one story. LLVM is trying to wall off AI prose in review-facing text while still allowing AI-touched code under human responsibility. The kernel is dropping a disclosure tag that did not buy useful signal and is arguing load-shedding versus burnout in the face of volume. Emacs is separating GNU legal caution from NonGNU pragmatism while still worrying that machine-authored blobs are hard for humans to maintain later. In every venue the beneficial case is real: faster drafts, stricter commit-message templates, analysis hooks, optional review aids. The extractive case is also real: walls of generated text, shallow understanding, and reviewers drafted into unpaid cleanup.

What remains unsettled is the operable boundary. “Human in the loop” is easy to say and hard to audit. Bans on generated communication invite both evasion (light edits of model text) and false accusation. Disclosure tags die when they become noise. Legal uncertainty around authorship sits beside a more immediate scarcity problem: attention. Projects are moving from etiquette pleas toward sharper defaults, knowing some good work will be refused along with the slop. How far those defaults go, and whether industry-symbiotic projects can stay outcome-oriented without hollowing out review culture, is still being negotiated in RFCs, maintainer summits, and package queues.