No-LLM contribution policies: HN argued ethics, maintainers described a review queue

On 28 October, MicroZig, the embedded Zig project, put a Strict No LLM / No AI Policy in its code of conduct: no LLM-generated code or prose, no LLMs for translation or editing, and "No LLMs for finding bugs." Days earlier, the r/opensource moderators had banned LLM-assisted projects. Hacker News gave the two stories 79 and 123 readable comments from 45 and 79 authors. Our read: most of it argued principle and enforceability, but the comments that explained the policies were describing a cost of review. Teams writing an AI-contribution rule should write that rule, not a rule about tools.

What the policy says, and what came before it

The policy is blunt. It also bans brainstorming: "If you use a chatbot to give you advice on a comment on the issue tracker, that comment is unwelcome." The maintainer, Matthew Knight, posted in the thread that the two preferences "are not compatible, one approach cannot coexist with the other," and that he has "no hard feelings for anyone that decides to make an LLM fork" (mattnite).

Two weeks earlier, on the same project, a project collaborator had reviewed an LLM-assisted contributor differently: "That is fine (imo), as long as you're not doing drive-by slop PRs. These have been rather good quality, and you've been testing on hardware (which is important)" (PR #1087). That comment names the actual acceptance test: quality, a person who stays, and evidence from real hardware.

Camp 1: the rule is unenforceable

A large share of the thread was about whether a tool ban can be checked. handoflixue: "the people in charge don't have any knowledge of whether I consulted an LLM while writing this comment" (handoflixue). The reply from yusefnapora is fair: "A rule doesn't have to be perfectly enforceable in order to serve a useful purpose. The rule assumes good intent on the participants" (yusefnapora).

Both are right, and neither tells a maintainer what to accept.

Camp 2: the cost lands on whoever triages

The comments that explained the policy described a queue. octoberfranklin, asked what LLM bug reports cost: "Untriaged 'bugs' that are based on implausible threat models. LLMs puke these out. It's extractive because a human has to triage them" (octoberfranklin).

nine_k put the responsibility on the submitter: the trouble with LLM bug reports is that submitters "have a poor / no idea themselves what the issue is, and whether it's really an issue. It's easy to flood maintainers with such reports" (nine_k). Gigachad described the pattern rather than the code: "An AI power user just drive by dumps a mountain of content and then leaves" (Gigachad).

The r/opensource thread said the same thing about projects instead of patches. Aurornis: "You can't tell if someone put 1000 hours into a project or 15 minutes of asking Claude Code to make a thing" (Aurornis). dw_arthur connected it to everyday agent work: "If you've run a bunch of LLM agent sessions concurrently you run into the human review bottleneck problem. That's all this is on a larger scale" (dw_arthur).

Camp 3: write the rule you mean

Several commenters proposed the rule they thought sat underneath. 8note: "dont submit stuff where only your llm session knows whats going on" (8note). rpdillon's personal policy: "Do whatever, but if you submit the code, you own it, and you better be able to act like you own it" (rpdillon). Gigachad again: a contributor who "genuinely understands the problem, has tested the code themselves and writes the PR description themselves" is indistinguishable from anyone else.

rpdillon also made the point we would underline: having to "read between the lines" of a code of conduct "is a serious bug".

Camp 4: banning bug-finding has a price

The pushback with a mechanism was about security. orangecat: "No LLMs for finding bugs. As of late 2026, this is gross negligence" (orangecat). That is strongly put, but the trade is real: a project that refuses LLM-found reports still has the bugs, and only the reporters change.

What each rule can actually check

The last two rows move work from the maintainer to the submitter, which is what the "extractive" complaint asks for. The PR #1087 comment had already applied the fourth one: "testing on hardware".

Our count. Across the 202 readable comments, "slop" appears in 23, "understand" or "explain" in 26, "enforce" in 10, and "review" in 5. The thread argued taste and enforcement and rarely named review as such, even though the policies exist because review time ran out.

Caveats. Two threads, sorted by us. Keyword counts match comment text, so one comment can count several times. The r/opensource announcement itself was not readable to us, so this post quotes only the HN discussion of it.