I can understand the no automated AI contribution point of view, but going overboard with the above that is also completely unenforceable makes the policy look dumb.
A project without everyone putting the same filter between them and the work they submit might help a project evolve in interesting and different ways.
Sources:
Indeed no hard feelings.
If an LLM finds a bug in some code, but you fail to report it because of a project's code of conduct regarding AI, does the bug even exist at all?
If you find a bug in some code, and use AI to help you find the fix, are you allowed to submit the fix? Or should you just let them "figure it out".
I'm sorry, but I can't take stances like this seriously. Policies like this are unhelpful. This reeks of the academic knee-jerk reaction of ban AI, without considering the reality that yes, students continue to use AI, even if you tell them not to. AI should be used responsibly. Ban the behaviour you don't want, don't ban the technology.
There was someone on a previous thread about zig who reported a bug and was ignored, ostensibly because he used LLMs to confirm the accuracy of his bug report before submission. https://news.ycombinator.com/item?id=49938732
if you want to submit an LLM found bug, you could instead donate the tokens directly to the maintainers, rather than making them read your agent outputs
> It is entirely valid for people to want to use LLMs for their projects and in their communities. It's also valid to want to keep them free of LLMs. Unfortunately those preferences are not compatible, one approach cannot coexist with the other. A choice needs to be made for MicroZig/ZEG projects. I've developed a preference for working without LLMs, and as I'm the most active maintainer of the project, shipping projects like the SYCL Badge, I'm imposing my preference.
> I have no hard feelings for anyone that decides to make an LLM fork of microzig.
I really wish a lot more of this debate could show that level of respect for the other side.
As of late 2026, this is gross negligence and any project with such a policy should be assumed to have a variety of easily exploitable vulnerabilities.
To me, it’s akin to running a classic car club and not wanting drivers to turn up in their 2026 GT3 RS. They appreciate the building process and the thought and effort that went into it. At least, that’s my interpretation after attending some meetups/conferences.
Tiberium•1h ago
Tiberium•1h ago
> Yeah we know you're working with an LLM. 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)
So it feels odd for them to suddenly change from this (clearly working) setup.
paaloeye•1h ago
Tiberium•59m ago
paaloeye•55m ago
vkaku•46m ago
paaloeye•36m ago
latexr•23m ago
Zig has had a similar policy for a while. Where are these myriad forks which accelerate faster, and the communities behind them?
nine_k•29m ago
But then use your own brain to understand the bug, its implications, maybe ways to fix it. Again, use whatever tools, as long as your mind forms a clear understanding, which you can operate on independent on any LLMs or whatever.
The problem with "LLM bug reports" is that the submitters run a machine tool to find something that looks like a bug, but 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. The "no AI" policy pushes the responsibility of doing proper assessment onto you, the submitter.
If you can use LLMs to produce a bug report with the quality of assessment equal or above that of a diligent qualified human bug reporter, godspeed.
sigmar•26m ago
that isn't what the policy says. It isn't just about writing the report.
> If you use a chatbot to give you advice on a comment on the issue tracker, that comment is unwelcome.
bilinguliar•20m ago
GuB-42•13m ago
To me "no LLMs for finding bugs" means what it means, which implicitly means "we prefer to have bugs than for you to use a LLM". It is weird, may result in worse code, but it can be justified for ideological reasons, and I mean, why not, it is your project, your rules.
In the unlikely even I contribute one day, reading this rule, I will turn off my LLMs completely and my submissions will probably have bugs that could have been avoided using a LLM based debugging pass, but that's the rule, and I won't discuss it because it is also the rule.
If the intent is to avoid flooding maintainers with bug reports, say "no LLMs for bug reporting".
iperov•26m ago
zamadatix•19m ago
> We know that if something gained somewhere, something lost somewhere.
I don't know that.
handoflixue•8m ago
Yeah, but that doesn't imply equivalent exchange.
If you care about being the best sprinter in the world, yeah, put in the time and effort! But if you just want to get to work, there's no way you can beat the speed of a car.
If you're one of the better bug-hunters in the world, you probably lose something by using an LLM. For the rest of us, it's increasingly like trying to race a car.
We definitely need both types - it's important having the humans who do have that top 1% understanding. But increasingly, for everyone else, LLMs outperform doing it by hand.