Hey, Matthew Knight here. I'll add what I had to say in the Discord announcement:
> 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'm wondering if you foresee remaining open to new contributors or focusing on a trusted set of like minded contributors? How much time are you willing to spend enforcing this policy? (To put my cards on the table I think it's good for projects to pursue different and incompatible agendas and if you are volunteering to conduct this experiment I think that is great and genuinely wish you the best, I'm just wondering whether this will become a tarpit that either soaks up all of your time or makes onboarding new contributors take an inordinate amount of time.)
> I'm just wondering whether this will become a tarpit that either soaks up all of your time or makes onboarding new contributors take an inordinate amount of time.
In an ideal world, LLM users would simply steer clear of trying to contribute instead of trying to hide it and direct their energy and tokens elsewhere
I think normal people would, couple projects I needed features added/bugs fixed and checked first if there were ai rules, there was, so instead of opening a pr just forked fixed and use my fork now. Not a big deal.
I agree the onus should be on people not to create a nuisance but I don't think it's a realistic expectation. Descriptively, normatively I agree that people ought to be considerate and reasonable.
I do not have a skin in the game for repository being ai vs no ai bit ( and I am biased as I work for one of the major AI labs now, need to put food on the table ) but, not directed toward you --
I genuinely do not understand why so many people that are pro-AI do not understand consent. There are people one comment downdown this tree talking about this being discrimination and harassment. It's not your project, you don't have a human right to contribute to it ... fork it ? direct your tokens elsewhere ? Wwhy the default with AI users seeming to try to nonconsensually force your way in while trying to hide it and consider it a one-up on the maintainer ?
I agree with what you've shared here, regarding personal choice etc. Can you say more about "No LLMs for finding bugs." What are some downsides that you've experienced or are protecting against?
I really appreciate the thoughtful message of "these two coding styles are simply incompatible, and as the lead maintainer I'm using the non-LLM style". No hate or hard feelings for those that prefer the alternative.
I really wish a lot more of this debate could show that level of respect for the other side.
So you are completely open minded about any form of expression in the known universe and do not under any circumstances tolerate harassment, discrimination or exclusion…unless it involves AI/LLMs. Got it.
Expression is as much about what is excluded as what is included. They've made it clear they aren't making a prescription for other people's projects. I don't see any reason to interpret this as an attack on other's expression rather than simply their own expression.
"No LLMs for finding bugs." I really don't get rules such as these, plus they're not really enforceable. There's a difference between using the LLM to write the bug report and using the LLM to find the bug (if you suspect there is one) to then report after manual checking, in human words.
Go ahead, use all the LLMs in the world for finding bugs! It's not different than finding bugs by fuzzing, sitting with gdb, or receiving a revelation in your dream.
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.
I assume the policy was written by rational, reasonable people, with a practical goal in mind: to prevent "AI slop", that is, dubious-quality, high-volume contributions by people who don't exactly understand how their PR works, and how the project works, but "computer says yes" because tests (which they also do not understand well) seem to pass.
If a submission (PR, bug report) is high-quality, and the person behind it is responsive and clueful, so that the useful parts of the submission can be taken, and problematic parts, fixed, then it does not matter what process has produced the code. It could as well be a Boltzmann brain [1].
Given that the author of the contribution actually got a grip on the problem, and on the solution, the limitation of "no AI use" is no longer load-bearing. Not only might it have been counterproductive — it's also unverifiable in practice. It becomes absurd, akin to a demand that the text must have been edited by Vim and not VSCode. It must be noted that a misguided policy may indeed force the contributor to delve in the depths of the process of PR creation, and showcase every manually undertaken step in an attempt to prove that no AI was involved. Ironically, it is no secret that many less scrupulous participants might leverage AI to imitate just that. It must be noted though that the decision ultimately belongs to the project maintainers.
(The above paragraph was hand-crafted for your and my entertainment.)
In short: by default I respect the authors of the policy and hence assume that they enact the policy for reasons that are rational, not religious.
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".
That's not my read, at least not if you give them enough credit to use their software.
My read is any LLM use should be opaque to them. You should be able to explain your bug find in your own words, have formatted as the project expects, not have any LLM generated comments (which trend towards being useless anyways)
The wording of the post is very clever, if you're green you read it and you say "I'm banned because I use Claude". If you're experienced enough you can read the message between the lines: "if you use LLMs, it should still have gone through your brain before it reaches mine, so I'm not turned into a meat puppet by proxy"
The fact we have different interpretations is the reason why it should be clarified.
Some people reject AI on a matter of principle. They may have a problem with the energy cost, the idea that AI companies are stealing the world knowledge for their own profit, that any use of LLMs will make you stupid, or that it does more harm than good overall. The code of conduct links to a short story by Isaac Asimov, you typically don't do that when your motives are purely technical.
If you say the quiet part out loud, the lemmings will take that as approval.
"Only thoughtful application of AI allowed" -> "Of course my usage of AI was thoughtful! My custom pi harness with 1M context project brain is very thoughtful!"
Not sure why you think this wouldn't be something they did on principle either though. Most open source projects are built on someone's personal principles: that's what motivates them to keep working.
(hence the recommendation someone's free to fork it and do the work themselves)
I've been battling this at work where management dumps a wall of claudeslop text in to a JIRA ticket highlighting some theoretical issue and it's incredibly difficult to understand what it's actually on about. And of course you can't ask the submitter because they don't know either.
This is when being very senior can help, as long as nobody above you has been consumed by the psychosis.
> And of course you can't ask the submitter because they don't know either.
At that moment I abandon the ticket with a comment that they can reopen once they can explain what they found, why it is an issue and should be fixed, etc.
If an LLM finds a bug, is that almost the same as an LLM writing code for you? You can write lazy code as a sketch, for example without thinking about nested loops in your head, and then just use an LLM that will fix this loop in the bug report?
This can be viewed as a level of AI usage: 10% (for example), where vibe coding is 100%.
I think any percentage of usage affects your personal mental sharpness. We know that if something gained somewhere, something lost somewhere. The only question is where the "loss" is, and how it will affect everything and everyone.
> We know that if something gained somewhere, something lost somewhere.
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.
I suppose that's the split between "writing code" the action and "writing code" the overall development process. I do agree there is some nuance in thoughts here often lost by the term getting overloaded.
> We know that if something gained somewhere, something lost somewhere.
Plus some of the issues are clearly written with LLMs, and apparently there's an active contributor who has been using LLMs to translate comments and help with code - https://github.com/ZigEmbeddedGroup/microzig/pull/1087:
> 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.
My point is that it seems extremely strange to do that when they have developers who use LLMs already contribute to the project. I feel like they'll either alienate people who are interested, or just not care to enforce their no-LLM policy.
The productive ones will just fork and accelerate faster. I understand the need for the mental muscle, this framing just sounds terrible at this point. Something something human scrutiny is not even an option the people want to consider.
It's not hypothetical to say that an LLM can write widely adopted, battle-tested, production code.
Claude Code would be another example.
Linux is still mostly human, but even Linus Torvalds has warmed up to the idea that LLMs are tools a skilled user can use to contribute there.
There's a lot of quieter, private examples where some company rewrote their entire back-end or internal tooling with an LLM. You just tend not to hear about it because "we used AI" is currently negative marketing/PR, so why say it out loud?
Remember, game engines can render millions of triangles per frame, and Claude Code struggles to render a few hundred characters on a monospace grid. I wouldn't hold it up as a shining beacon of quality.
What a poor example. Epic Games’ launcher is popular despite its software, not because of it, and in large part because they give away free games every week.
> battle-tested
You’re just throwing words around. You can’t in good faith call something that is barely out “battle-tested”.
> Claude Code would be another example.
Claude Code is widely regarded as a mess and bad software, and for good reason (see sibling comment).
I don’t understand why people get so annoyed at policies like this. Zig seems to be a niche community that really embraces the people and craft of programming as opposed to being just another language.
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.
I'm actually seeing a lot less annoyance at this policy -vs- others like it. I'd assume that's partly because the policy makes sense here, and partly because the policy was respectfully communicated instead of implying that AI-users are committing some sort of cardinal sin.
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.
It really depends on what the application does. It's only really a problem if it's internet-facing, and even then, the harm is limited to the application's own permission set. I don't really care if someone can chain together zero-day exploits to "pwn" my lightbulbs.
A lot of the recent major exploits like php2shell require a fair amount of effort to use, so unless you're a major public figure or holding on to something very valuable, there's not a lot of reason to be concerned.
Obviously, if you're writing a password manager, it's a very different story and I'd be horrified by such a policy there. But you've got to make an argument that this specific app is actually a target
> I don't really care if someone can chain together zero-day exploits to "pwn" my lightbulbs.
The point of pwning your lightbulb is not to decide whether it's bright or dark in your house. It's valuable as a residential proxy with a good IP reputation, to be sold to the highest bidder who wants to do something they don't want traced to their own IP.
There will probably be a time when it's impossible to determine if content came from an LLM or a human. We're currently in the, "It's been 'shopped, I can tell by the pixels" stage.
I think the idea is to weed out the obvious stuff and have a rule you can point to. When someone opens 20 PRs in a day with an entire novel in the PR description. You can just close them without having to sink effort in to each one. The LLM signs are less in the code itself and the patterns of how the person interacts with the project. A normal contributor might join the IRC, be involved in the project, start on smaller issues and work up. An AI power user just drive by dumps a mountain of content and then leaves.
If a contributor genuinely understands the problem, has tested the code themselves and writes the PR description themselves, it would be indistinguishable from human written code anyway.
I’m not so sure, it currently feels like forgotten coding practice, missed documentation, intersystem reasoning blunders, configuration mistakes, lack of test coverage are all massive tells that a human wrote the code.
Agents have us beat and we can’t win back the ground.
Or if it does, it could be hundreds of years in the future.
But maybe it'll be next year? LOL.
As it is, we seem to be developing detection techniques at a good clip and the way current LLM tech works it doesn't seem like there is a path towards avoiding detection... Plus, humans are genuinely very good at self-tuning to detect LLM output.
In the spirit of a balanced discussion, I have to admit that said extension is full of flaws and is nowhere reliable. However it was/is widely adopted amongst the Zig team.
I remember how someone used it to guess vibe-codeness of the infamous and long awaited bun2rust article by Jared Summer from Anthropic. It was completely off-base vs real numbers of em/en dashes and hyphens.
Interesting choice. I'll be interested in how it turns out. There's essentially 0 chance any contributors are better than current models, but sacrifices have to be made to stay pure, I suppose.
> No LLMs for brainstorming and then sharing the results of that brainstorming, even if you create the prose.
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.
Unenforceable - sure, but it's interesting and I see the logic. While LLMs are extremely useful, I find they homongenise things. Claude text is instantly identifiable and now all my co-workers presentations and docs sound like it. I'm sure that extra effort helps differentiate things (so many LLM generated sites look the same so not many people put in the effort).
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.
It's exactly as enforceable as when projects require you to swear that you can legally assign copyright of your submissions to the entity that runs the project, and/or swear that your submissions don't infringe on anyone's patents, and/or -as the ReactOS project does- swear that you've never seen the code that the project is reimplementing.
If someone swears that they're conforming to the rules and you later find out that they lied, then you ban them forever, publicly announce why, and -if needed- purge their contributions and do your best to alert affected users about the tainted versions. These sorts of policies work for the same reason ordinary doors and door locks work: most folks aren't profoundly antisocial shitbags.
It's not enforceable, because the people in charge don't have any knowledge of whether I consulted an LLM while writing this comment.
You said it yourself - the enforceable policy is a a different, and much more reasonable policy. If the rule is "ultimately" something else, you can in fact just make that the rule. Or include a parenthetical explanation.
Rules are the ideal place for being pedantic and detailed! That's the whole point of rules - ultimately, the rule is the rule that was actually written down. Not anything else.
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
i think its probably asking people to not submit things they dont understand themselves.
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
You’re saying that like it’s a gotcha, but it’s completely reasonable, and a later section clarifies that discussing the CoC elsewhere is fine, just not on the fora that are focused on technical issues.
Basically, the person running the project has made their stance clear, they’re not interested in debating it, and if you don’t like it, take your patronage elsewhere. Clear and straightforward.
Hey, Matthew Knight here. I'll add what I had to say in the Discord announcement:
> 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'm wondering if you foresee remaining open to new contributors or focusing on a trusted set of like minded contributors? How much time are you willing to spend enforcing this policy? (To put my cards on the table I think it's good for projects to pursue different and incompatible agendas and if you are volunteering to conduct this experiment I think that is great and genuinely wish you the best, I'm just wondering whether this will become a tarpit that either soaks up all of your time or makes onboarding new contributors take an inordinate amount of time.)
> I'm just wondering whether this will become a tarpit that either soaks up all of your time or makes onboarding new contributors take an inordinate amount of time.
In an ideal world, LLM users would simply steer clear of trying to contribute instead of trying to hide it and direct their energy and tokens elsewhere
I think normal people would, couple projects I needed features added/bugs fixed and checked first if there were ai rules, there was, so instead of opening a pr just forked fixed and use my fork now. Not a big deal.
I agree the onus should be on people not to create a nuisance but I don't think it's a realistic expectation. Descriptively, normatively I agree that people ought to be considerate and reasonable.
I do not have a skin in the game for repository being ai vs no ai bit ( and I am biased as I work for one of the major AI labs now, need to put food on the table ) but, not directed toward you --
I genuinely do not understand why so many people that are pro-AI do not understand consent. There are people one comment downdown this tree talking about this being discrimination and harassment. It's not your project, you don't have a human right to contribute to it ... fork it ? direct your tokens elsewhere ? Wwhy the default with AI users seeming to try to nonconsensually force your way in while trying to hide it and consider it a one-up on the maintainer ?
I agree with what you've shared here, regarding personal choice etc. Can you say more about "No LLMs for finding bugs." What are some downsides that you've experienced or are protecting against?
Untriaged "bugs" that are based on implausible threat models.
LLMs puke these out.
It's extractive because a human has to triage them.
I really appreciate the thoughtful message of "these two coding styles are simply incompatible, and as the lead maintainer I'm using the non-LLM style". No hate or hard feelings for those that prefer the alternative.
I really wish a lot more of this debate could show that level of respect for the other side.
Do you perform arbitrary ethical purity tests for other types of contributions? Or just this one solitary rule because the media is talking about it?
So you are completely open minded about any form of expression in the known universe and do not under any circumstances tolerate harassment, discrimination or exclusion…unless it involves AI/LLMs. Got it.
Expression is as much about what is excluded as what is included. They've made it clear they aren't making a prescription for other people's projects. I don't see any reason to interpret this as an attack on other's expression rather than simply their own expression.
Playing the victim card is certainly a choice
"No LLMs for finding bugs." I really don't get rules such as these, plus they're not really enforceable. There's a difference between using the LLM to write the bug report and using the LLM to find the bug (if you suspect there is one) to then report after manual checking, in human words.
Go ahead, use all the LLMs in the world for finding bugs! It's not different than finding bugs by fuzzing, sitting with gdb, or receiving a revelation in your dream.
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.
>Again, use whatever tools, as long as your mind forms a clear understanding, which you can operate on independent on any LLMs or whatever.
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.
I assume the policy was written by rational, reasonable people, with a practical goal in mind: to prevent "AI slop", that is, dubious-quality, high-volume contributions by people who don't exactly understand how their PR works, and how the project works, but "computer says yes" because tests (which they also do not understand well) seem to pass.
If a submission (PR, bug report) is high-quality, and the person behind it is responsive and clueful, so that the useful parts of the submission can be taken, and problematic parts, fixed, then it does not matter what process has produced the code. It could as well be a Boltzmann brain [1].
Given that the author of the contribution actually got a grip on the problem, and on the solution, the limitation of "no AI use" is no longer load-bearing. Not only might it have been counterproductive — it's also unverifiable in practice. It becomes absurd, akin to a demand that the text must have been edited by Vim and not VSCode. It must be noted that a misguided policy may indeed force the contributor to delve in the depths of the process of PR creation, and showcase every manually undertaken step in an attempt to prove that no AI was involved. Ironically, it is no secret that many less scrupulous participants might leverage AI to imitate just that. It must be noted though that the decision ultimately belongs to the project maintainers.
(The above paragraph was hand-crafted for your and my entertainment.)
In short: by default I respect the authors of the policy and hence assume that they enact the policy for reasons that are rational, not religious.
[1]: https://en.wikipedia.org/wiki/Boltzmann_brain
Without a policy, I refuse to have a clear understanding!
Then it should be clarified.
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".
That's not my read, at least not if you give them enough credit to use their software.
My read is any LLM use should be opaque to them. You should be able to explain your bug find in your own words, have formatted as the project expects, not have any LLM generated comments (which trend towards being useless anyways)
The wording of the post is very clever, if you're green you read it and you say "I'm banned because I use Claude". If you're experienced enough you can read the message between the lines: "if you use LLMs, it should still have gone through your brain before it reaches mine, so I'm not turned into a meat puppet by proxy"
The fact we have different interpretations is the reason why it should be clarified.
Some people reject AI on a matter of principle. They may have a problem with the energy cost, the idea that AI companies are stealing the world knowledge for their own profit, that any use of LLMs will make you stupid, or that it does more harm than good overall. The code of conduct links to a short story by Isaac Asimov, you typically don't do that when your motives are purely technical.
They can't clarify it.
If you say the quiet part out loud, the lemmings will take that as approval.
"Only thoughtful application of AI allowed" -> "Of course my usage of AI was thoughtful! My custom pi harness with 1M context project brain is very thoughtful!"
Not sure why you think this wouldn't be something they did on principle either though. Most open source projects are built on someone's personal principles: that's what motivates them to keep working.
(hence the recommendation someone's free to fork it and do the work themselves)
I've been battling this at work where management dumps a wall of claudeslop text in to a JIRA ticket highlighting some theoretical issue and it's incredibly difficult to understand what it's actually on about. And of course you can't ask the submitter because they don't know either.
This is when being very senior can help, as long as nobody above you has been consumed by the psychosis.
> And of course you can't ask the submitter because they don't know either.
At that moment I abandon the ticket with a comment that they can reopen once they can explain what they found, why it is an issue and should be fixed, etc.
> No LLMs for finding bugs.
That's what it says, literally. I'm sorry but for a programming language project.. That's the most human slop of a policy I have seen in a long time.
Low effort, human slop.
If an LLM finds a bug, is that almost the same as an LLM writing code for you? You can write lazy code as a sketch, for example without thinking about nested loops in your head, and then just use an LLM that will fix this loop in the bug report? This can be viewed as a level of AI usage: 10% (for example), where vibe coding is 100%. I think any percentage of usage affects your personal mental sharpness. We know that if something gained somewhere, something lost somewhere. The only question is where the "loss" is, and how it will affect everything and everyone.
> We know that if something gained somewhere, something lost somewhere.
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.
I suppose that's the split between "writing code" the action and "writing code" the overall development process. I do agree there is some nuance in thoughts here often lost by the term getting overloaded.
> We know that if something gained somewhere, something lost somewhere.
I don't know that.
Plus some of the issues are clearly written with LLMs, and apparently there's an active contributor who has been using LLMs to translate comments and help with code - https://github.com/ZigEmbeddedGroup/microzig/pull/1087:
> 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.
Keep in mind the project HAS just adopted the policy
My point is that it seems extremely strange to do that when they have developers who use LLMs already contribute to the project. I feel like they'll either alienate people who are interested, or just not care to enforce their no-LLM policy.
Said developers will decide: either fork or retire their LLMs. As simple as that. Nothing strange at all.
The productive ones will just fork and accelerate faster. I understand the need for the mental muscle, this framing just sounds terrible at this point. Something something human scrutiny is not even an option the people want to consider.
> The productive ones will just fork and accelerate faster.
Zig has had a similar policy for a while. Where are these myriad forks which accelerate faster, and the communities behind them?
Yeah, where are they?
Let's see when they deliver real features alone which are widely adopted and battle-tested in production.
https://www.ign.com/articles/we-vibe-coded-a-new-epic-games-...
It's not hypothetical to say that an LLM can write widely adopted, battle-tested, production code.
Claude Code would be another example.
Linux is still mostly human, but even Linus Torvalds has warmed up to the idea that LLMs are tools a skilled user can use to contribute there.
There's a lot of quieter, private examples where some company rewrote their entire back-end or internal tooling with an LLM. You just tend not to hear about it because "we used AI" is currently negative marketing/PR, so why say it out loud?
Remember when the Claude Code devs compared their TUI to a game engine while trying to explain why it was so buggy and slow?
https://x.com/trq212/status/2014051501786931427
Remember, game engines can render millions of triangles per frame, and Claude Code struggles to render a few hundred characters on a monospace grid. I wouldn't hold it up as a shining beacon of quality.
> widely adopted
What a poor example. Epic Games’ launcher is popular despite its software, not because of it, and in large part because they give away free games every week.
> battle-tested
You’re just throwing words around. You can’t in good faith call something that is barely out “battle-tested”.
> Claude Code would be another example.
Claude Code is widely regarded as a mess and bad software, and for good reason (see sibling comment).
I don’t understand why people get so annoyed at policies like this. Zig seems to be a niche community that really embraces the people and craft of programming as opposed to being just another language.
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.
I'm actually seeing a lot less annoyance at this policy -vs- others like it. I'd assume that's partly because the policy makes sense here, and partly because the policy was respectfully communicated instead of implying that AI-users are committing some sort of cardinal sin.
No LLMs for finding bugs.
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.
It really depends on what the application does. It's only really a problem if it's internet-facing, and even then, the harm is limited to the application's own permission set. I don't really care if someone can chain together zero-day exploits to "pwn" my lightbulbs.
A lot of the recent major exploits like php2shell require a fair amount of effort to use, so unless you're a major public figure or holding on to something very valuable, there's not a lot of reason to be concerned.
Obviously, if you're writing a password manager, it's a very different story and I'd be horrified by such a policy there. But you've got to make an argument that this specific app is actually a target
> I don't really care if someone can chain together zero-day exploits to "pwn" my lightbulbs.
The point of pwning your lightbulb is not to decide whether it's bright or dark in your house. It's valuable as a residential proxy with a good IP reputation, to be sold to the highest bidder who wants to do something they don't want traced to their own IP.
There will probably be a time when it's impossible to determine if content came from an LLM or a human. We're currently in the, "It's been 'shopped, I can tell by the pixels" stage.
I think the idea is to weed out the obvious stuff and have a rule you can point to. When someone opens 20 PRs in a day with an entire novel in the PR description. You can just close them without having to sink effort in to each one. The LLM signs are less in the code itself and the patterns of how the person interacts with the project. A normal contributor might join the IRC, be involved in the project, start on smaller issues and work up. An AI power user just drive by dumps a mountain of content and then leaves.
If a contributor genuinely understands the problem, has tested the code themselves and writes the PR description themselves, it would be indistinguishable from human written code anyway.
I think for the past year anyone determined enough could direct Claude to make the codebase look purely human.
I’m not so sure, it currently feels like forgotten coding practice, missed documentation, intersystem reasoning blunders, configuration mistakes, lack of test coverage are all massive tells that a human wrote the code.
Agents have us beat and we can’t win back the ground.
I don't believe that time will ever arrive.
Or if it does, it could be hundreds of years in the future.
But maybe it'll be next year? LOL.
As it is, we seem to be developing detection techniques at a good clip and the way current LLM tech works it doesn't seem like there is a path towards avoiding detection... Plus, humans are genuinely very good at self-tuning to detect LLM output.
The policy in question is based Zig's LLM policies, per the most active maintainer of the project, Matthew Knight — the author of Em Dash Counter
Sources:
- https://github.com/mattnite
- https://github.com/mattnite/em-dash-counter
- https://mattnite.net
In the spirit of a balanced discussion, I have to admit that said extension is full of flaws and is nowhere reliable. However it was/is widely adopted amongst the Zig team.
I remember how someone used it to guess vibe-codeness of the infamous and long awaited bun2rust article by Jared Summer from Anthropic. It was completely off-base vs real numbers of em/en dashes and hyphens.
Interesting choice. I'll be interested in how it turns out. There's essentially 0 chance any contributors are better than current models, but sacrifices have to be made to stay pure, I suppose.
Just read the Asimov story linked in the policy, it was a good read, thank you for introducing me to it.
Matthew, the main maintainer, has no hard feeling if someone decides to make an LLM fork. Forks are welcome basically.
Indeed no hard feelings.
Can somebody explain what happened at 0216Z here? https://news.social-protocols.org/stats?id=50282865
I genuinely don't understand.
This is a clever rule. It will not be an obstacle for people who are capable of creating higher quality output using LLMs.
Why are AI pushers always scheming to go against people's wishes like this? It's incredibly anti-social.
"I'd like to request a vegetarian meal."
"This is a clever request. It will not be an obstacle for a good chef who knows the best spices to use to disguise meat."
> No LLMs for brainstorming and then sharing the results of that brainstorming, even if you create the prose.
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.
Unenforceable - sure, but it's interesting and I see the logic. While LLMs are extremely useful, I find they homongenise things. Claude text is instantly identifiable and now all my co-workers presentations and docs sound like it. I'm sure that extra effort helps differentiate things (so many LLM generated sites look the same so not many people put in the effort).
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.
I kinda wish I could identify it like you guys. Then again, I might be more depressed if I could.
> ...is also completely unenforceable...
It's exactly as enforceable as when projects require you to swear that you can legally assign copyright of your submissions to the entity that runs the project, and/or swear that your submissions don't infringe on anyone's patents, and/or -as the ReactOS project does- swear that you've never seen the code that the project is reimplementing.
If someone swears that they're conforming to the rules and you later find out that they lied, then you ban them forever, publicly announce why, and -if needed- purge their contributions and do your best to alert affected users about the tainted versions. These sorts of policies work for the same reason ordinary doors and door locks work: most folks aren't profoundly antisocial shitbags.
it is enforceable, just the wrong rule.
the rule is ultimately "dont submit stuff where only your llm session knows whats going on"
if you brainstorm with an llm, then rewrite the llm prose but have no understanding, youve still broken the rule.
if you understand what it suggested, why, and so on, then you do know whats up, and thats unenforceable, but who cares
It's not enforceable, because the people in charge don't have any knowledge of whether I consulted an LLM while writing this comment.
You said it yourself - the enforceable policy is a a different, and much more reasonable policy. If the rule is "ultimately" something else, you can in fact just make that the rule. Or include a parenthetical explanation.
Rules are the ideal place for being pedantic and detailed! That's the whole point of rules - ultimately, the rule is the rule that was actually written down. Not anything else.
> No LLMs for finding bugs.
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.
It is deeply unserious.
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
i think its probably asking people to not submit things they dont understand themselves.
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
What if the behavior you don’t want is reliance on the technology?
"Examples of unacceptable behavior by participants include...discussing this Code of Conduct."
You’re saying that like it’s a gotcha, but it’s completely reasonable, and a later section clarifies that discussing the CoC elsewhere is fine, just not on the fora that are focused on technical issues.
Basically, the person running the project has made their stance clear, they’re not interested in debating it, and if you don’t like it, take your patronage elsewhere. Clear and straightforward.
[flagged]
[flagged]
[dead]
[flagged]
I don't think Andrew is arrogant. But if he was, he's gained that privilege by 10 years of working on Zig.
Hard feelings?
[flagged]