ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
0% Positive
Analyzed from 588 words in the discussion.
Trending Topics
#code#generated#llm#write#doesn#seem#seems#maintainer#bans#stringent

Discussion (8 Comments)Read Original on HackerNews
As AI bans go, this one doesn't seem too stringent if you disclose AI and actually check what it's doing.
> All contributions are expected to be made by humans. AI tools may be used for research and learning, but all content in contributions must originate from and be understood by the contributor. This includes code, documentation, issues, security reports, pull request descriptions, and comments in all Void Linux community spaces.
This reads as though you can't use an LLM to write any code at all.
So you can use LLMs to write lots of code. It just can't be the code that you finally submit as the work you own and maintain. That might be a blunt instrument but it does seem likely to help ensure that compliant maintainers retain a (historically, at least) normal level of connection to their code regardless of what tools they use during development. I can imagine some developers who particularly care about the quality of some project choosing to impose this exact same discipline on themselves, even if for their dayjob or other personal projects they almost exclusively use LLM-generated code.
Maybe that's annoying, maybe it slows down development of the project, and it's fair for a maintainer to decide that's not how they want to work. But it's not the same as banning the use of LLMs to write code in connection with the project.
> As AI bans go, this one doesn't seem too stringent if you disclose AI and actually check what it's doing.
I'm not arguing for or against the policy, but the policy as-written reads to me a complete and total ban on the submission of any and all generated text, which is not what that commenter suggested. I'm not sure you could possibly make it more stringent without getting into the territory of thought police.
Maybe that's not what the authors of the policy intended but that's how it reads imo
Since on average the people don't have patience and don't act with responsibility, spaghetti gets everywhere. It may sound tempting to ban the AI-generated code, but the issue is not the AI, but the lack of responsibility and potentially the the lack of experience of the developers whom are contributing with this spaghetti slop.
The judgment should go for the end result and the author is responsible if the code is bad. Add exponential back-off to contributions if they are bad.
It is also possible to brute-force maintainers with too many things to review, but you can also limit the lines of code they can contribute, unless they have some sort of reputation.
Banning the AI just means that everyone is using it, but nobody is saying it aloud. Since it saves so much time when used correctly.
Seems like a very dumb hill to die on in 2026
That said if they extended to kernel-space, it seems like NetBSD would be the other *nix like alternative (Google's AI summary says they're the only BSD to take a strict no-ai stance).
Or Gnu HURD.