"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.
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.
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.
> 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.
Love Zig. Great language, main one I use. Largely with agents, actually.
Sick of Andrew's arrogance. It's pervasive in the little clique of software heroes who are the only ones who get to touch his precious codebase now, along with the fratboy culture of contempt which always accompanies that kind of behavior.
Of course it's being cargo-culted by the embedded group, how else are they going to get Senpai to notice them.
Doesn't bode well for things going forward. Fortunately Zig was mostly done before AK started disappearing up his own posterior, so it's just a case where we'll have to accept a good language with some bizarre warts, rather than the truly excellent one it was shaping up to be.
So it goes. Good luck with that steel drivin', John Henry.
"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.
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 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
> 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.
Matthew, the main maintainer, has no hard feeling if someone decides to make an LLM fork. Forks are welcome basically.
Indeed no hard feelings.
> 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.
Love Zig. Great language, main one I use. Largely with agents, actually.
Sick of Andrew's arrogance. It's pervasive in the little clique of software heroes who are the only ones who get to touch his precious codebase now, along with the fratboy culture of contempt which always accompanies that kind of behavior.
Of course it's being cargo-culted by the embedded group, how else are they going to get Senpai to notice them.
Doesn't bode well for things going forward. Fortunately Zig was mostly done before AK started disappearing up his own posterior, so it's just a case where we'll have to accept a good language with some bizarre warts, rather than the truly excellent one it was shaping up to be.
So it goes. Good luck with that steel drivin', John Henry.
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?