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.
Tiberium 50 minutes ago [-]
"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.
iperov 9 minutes ago [-]
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.
zamadatix 3 minutes ago [-]
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.
nine_k 13 minutes ago [-]
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.
sigmar 9 minutes ago [-]
>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.
bilinguliar 3 minutes ago [-]
Without a policy, I refuse to have a clear understanding!
Tiberium 45 minutes ago [-]
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.
paaloeye 44 minutes ago [-]
Keep in mind the project HAS just adopted the policy
Tiberium 42 minutes ago [-]
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.
paaloeye 38 minutes ago [-]
Said developers will decide: either fork or retire their LLMs. As simple as that.
Nothing strange at all.
vkaku 29 minutes ago [-]
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.
paaloeye 19 minutes ago [-]
Let's see when they deliver real features alone which are widely adopted and battle-tested in production.
latexr 6 minutes ago [-]
> 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?
pugworthy 4 minutes ago [-]
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.
paaloeye 45 minutes ago [-]
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
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.
sigmar 12 minutes ago [-]
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
sarchertech 10 minutes ago [-]
What if the behavior you don’t want is reliance on the technology?
paaloeye 42 minutes ago [-]
Matthew, the main maintainer, has no hard feeling if someone decides to make an LLM fork. Forks are welcome basically.
Indeed no hard feelings.
nnx 50 minutes ago [-]
> 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.
janice1999 45 minutes ago [-]
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.
samatman 42 minutes ago [-]
[flagged]
paaloeye 32 minutes ago [-]
I don't think Andrew is arrogant. But if he was, he's gained that privilege by 10 years of working on Zig.
paaloeye 41 minutes ago [-]
Hard feelings?
Rendered at 01:56:59 GMT+0000 (Coordinated Universal Time) with Vercel.
> 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.
> We know that if something gained somewhere, something lost somewhere.
I don't know that.
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.
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.
> 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.
Zig has had a similar policy for a while. Where are these myriad forks which accelerate faster, and the communities behind them?
Sources:
- https://github.com/mattnite
- https://github.com/mattnite/em-dash-counter
- https://mattnite.net
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
Indeed no hard feelings.
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.