Filed a compiler bug related to dwarf tables that screws up debugging and line of code coverage that they completely ignored, just because I mentioned that I had every LLM check it to confirm it's a bug, since all I know is what kcov and every coverage tool generates incorrect coverage data for my repo, for 100% certain.
Wow I thought surely they wouldn't object to using AI to confirm bugs, but they really do.
Tbf I guess as a popular open source project not using AI to fix bugs, they probably already have more open bugs than they can ever fix so it doesn't really help them for people to find more.
I would imagine his bug was actually ignored just because Zig has 2700 open bugs, rather than some AI policy violation.
Claude Code has 13.4k open bugs: <a href="https://github.com/anthropics/claude-code/issues" rel="nofollow">https://github.com/anthropics/claude-code/issues
Show me a popular open source project that doesn't have a large number of open issues and I'll show you one that has a triage bot auto-close them.
Some have both, despite using an auto-close bot! OC is at 4.6K open and 24K closed issues. <a href="https://github.com/anomalyco/opencode/issues" rel="nofollow">https://github.com/anomalyco/opencode/issues
Gotta admit it's weird that they haven't set up Claude to fix them! Tbf my threshold for "AI now writes good enough code" was Astra or Opus 5.5 and they only just released that.
They don’t, at least not any more. Andrew Kelley has explicitly stated that he sees the value of using LLMs to uncover bugs. Inspired by sqllite project.
They may just be taking the slow route of rejecting by default until they can be sure that the usage of LLMs provides long term value. I don’t see anything wrong with that. If you’re writing robust software, using LLMs at this stage is a bit of a gamble. We don’t fully know the long term effects on code quality yet.
Project maintainers know what level of AI use is acceptable for themselves, and quantifying it and enforcing it for random contributors is very difficult.
He sees the value of using LLMs... only after performing NASA-level verification and fully comprehensive fuzzing using traditional tools. Since Zig has not done those things, LLM-generated bugs are still banned.
If there's an edict that no one is allowed to bring up the topic, how can someone change this part of the code of conduct?
Asking non-rhetorically. It seems like one position "ai in any circumstance = bad" is being enforced. The commenter above didn't even understand why he was ignored.
Interesting to hear! We maintain the project Antfly (entirely zig) and have been nervous about bringing issues to the zig folks or asking questions because of our ai usage.
We’re quite knowledgeable and thoughtful folks fwiw
I think I’ve seen you are a core team member or contributor? I remember your tag?
So for instance because of the size of our codebase our project has pushed Zig to some of the edges, specifically we end up hitting a bug when using llvm and zig on arm64 (Mac and Linux) where it seems to be caused by some configuration Zig passes through to LLVM. I’ve used codex and claude to help me diagnose and find the bug (we use nix’s glibc zig to circumvent the problem now). I now understand the root cause but am not sure what the proper fix would be. But I’ve not known whether or not even raising the issue would break the terms of contributing? Would raising the issue break the implicit agreement?
I would suggest just starting by filling out the bug report template, i.e. steps to reproduce, expected behavior, and observed behavior. If for some reason you can't provide a reasonable reproduction, the symptoms on their own can sometimes be enough for us to make an educated guess at what's going wrong.
Regarding whether you should post the root cause analysis: Per the current policy, the answer would have to be no.
I do personally have more nuanced thoughts on this, and I started typing them out... but then I realized that my reply was getting dangerously close to blog post length, so I decided to restrain myself and commit to turning it into an actual blog post later. In a nutshell, though, the problem is that even if there is such a thing as responsible use of LLMs for bug analysis, the only way we can currently be confident that someone possesses the required qualities for that is by working with them for a while.
I understand, maybe one day I'll have the chance to hear the blog posts' worth of thought on the matter!
<a href="https://codeberg.org/ziglang/zig/issues/37060" rel="nofollow">https://codeberg.org/ziglang/zig/issues/37060 I opened the issue and can give you the agent generated RCA on the matter if you all want it in issue 604 on antfly's github but I understand that's against policy and totally respect that.
Appreciate all the work you guys do and have been following the whole Zig project since inception fwiw!
The second part affirms that it is centralized. There is nothing wrong with that except saying that because you can leave the community and go elsewhere, it is ipso facto decentralized.
I’ve not found the zig folks to ban dissent, they engage in a lot of thoughtful dialog. Just because they’ve made a different decision for how they take contributions than other people agree with doesn’t make them a cult?
The things you've quoted and your conclusion feel at odds. They just don't want AI contributions, and they, like a lot of the world, are bored of hearing about AI. Is it really too much to ask?
>Even in projects where I use LLM liberally, I would rather not read or have to engage with your LLM output.
I don't want to read LLM output on a project either. But you may have misread the quoted section, it isn't saying "you can't post LLM output," it is saying you can't ask an LLM to advise/critique your own comment before posting it.
>>If you use a chatbot to give you advice on a comment on the issue tracker, that comment is unwelcome.
It's clearly a hobby project (constant breakages, the maintainer getting into politics, rejecting some safety mechanisms, the anti-LLM crusade, a strange focus on esoteric targets with little to no commercial significance), but the maintainer does not admit that it is a hobby project.
Reading their comment it sounds like they wanted to confirm the bug existed with AI, not sure they ever said they had AI write the code. Why have such a dumb policy?
If they really insist on no LLM involvement at all then they're going to fall behind and lose out. Your LLM use case seems really very conservative - you didn't write any code with it, you just use it to confirm the bug. There are many OSS projects that are also taking a similar hardline against LLMs - people are going to fork them and then move on. I've had LLMs fix bugs/add features to a couple of projects like this and, well, they're missing out on the fixes/added features that I'm using locally.
I'd really love to figure out how to stay behind, but the people who keep insisting I'll be left behind are doing their level best to prevent it.
How do you evaluate this? Have you tried looking for a job? Or compared your project with a similar project where people are using AI and you are not? Or you’re just staying put and waiting to see what happens?
It's remarkable how easily these idiots can be conditioned into parroting the usual FOMO lines without question. Same people would've had me think I'm a fucking moron for not buying ugly monkey pictures during the NFT bubble.
I'm thinking their lives must be absolutely dreadful for this constant fear of being left behind.
Seems like "parallel construction" where you show you actually understand and can explain the issue independent of an LLM would be the way to go. No need to mention how you found the bug as long as you can explain what the bug is, why it matters, and how to repro.
Lying to get around a project policy you disagree with is immature. They have the right to run things the way they want, either accept their rules or leave the project be.
Encountering something that seems incorrect, and proving something is a bug and not just YOUR user error, AND reproducing it minimally - turns out to not be easy when it's a low-level compiler issue, and YOU'RE not an expert, especially when it relates to Dwarf tables...
Typically, any time you think you've found a compiler error, you're using it wrong...
If it's a real bug, you can just report what you know and leave it at that. You don't need to embellish it with random guesses about a root cause.
Okay: "I compile this input and the linker crashes."
Not okay: "I compile this input and the linker crashes. Also here's 10 paragraphs of slop about dwarf tables, which I can't even evaluate the accuracy of since I'm not an expert."
> Typically, any time you think you've found a compiler error, you're using it wrong...
Yes, if you can't figure out if it's a bug, the bug tracker is the wrong place to get help. Ask in a community forum instead.
> Not okay: "I compile this input and the linker crashes. Also here's 10 paragraphs of slop about dwarf tables, which I can't even evaluate the accuracy of since I'm not an expert."
It's a 20-line file with a few commands to run it to reproduce it. Not 10 paragraphs of slop.
Presumably that is much more helpful than - here's my gigantic repo, good luck running my tests, also good luck finding the bug.
> here's my gigantic repo, good luck running my tests
What about my comment made you think I was suggesting not to give repro steps?
> also good luck finding the bug
But yes actually, this half is true. It's better to give them no extra information, than to give too much information that you have no idea if it's true or not.
I reported a bug and waited for a year. one day it was merged. the thing is that there are a looot of bugs and the team is small, so your turn might not have come up yet
jabedude · · focus · HN ↗
abc42 · · focus · HN ↗
onlyrealcuzzo · · focus · HN ↗
bendmorris · · focus · HN ↗
IshKebab · · focus · HN ↗
Tbf I guess as a popular open source project not using AI to fix bugs, they probably already have more open bugs than they can ever fix so it doesn't really help them for people to find more.
I would imagine his bug was actually ignored just because Zig has 2700 open bugs, rather than some AI policy violation.
bendmorris · · focus · HN ↗
Show me a popular open source project that doesn't have a large number of open issues and I'll show you one that has a triage bot auto-close them.
esafak · · focus · HN ↗
IshKebab · · focus · HN ↗
acedTrex · · focus · HN ↗
audunw · · focus · HN ↗
<a href="https://youtu.be/zwi5b5xSsKA?is=PTjJJjSnVMdRuZag" rel="nofollow">https://youtu.be/zwi5b5xSsKA?is=PTjJJjSnVMdRuZag
They may just be taking the slow route of rejecting by default until they can be sure that the usage of LLMs provides long term value. I don’t see anything wrong with that. If you’re writing robust software, using LLMs at this stage is a bit of a gamble. We don’t fully know the long term effects on code quality yet.
saghm · · focus · HN ↗
unleaded · · focus · HN ↗
Capricorn2481 · · focus · HN ↗
csande17 · · focus · HN ↗
unclad5968 · · focus · HN ↗
bendmorris · · focus · HN ↗
sigmar · · focus · HN ↗
>No LLMs for finding bugs.
>No talking about use of chatbot/LLM services.
I've said it before and I'll say it again- it's a cult that bans dissent
alexrp · · focus · HN ↗
sigmar · · focus · HN ↗
Asking non-rhetorically. It seems like one position "ai in any circumstance = bad" is being enforced. The commenter above didn't even understand why he was ignored.
alexrp · · focus · HN ↗
To clarify, do you mean someone who isn't part of the core team?
kingcauchy · · focus · HN ↗
We’re quite knowledgeable and thoughtful folks fwiw
I think I’ve seen you are a core team member or contributor? I remember your tag?
alexrp · · focus · HN ↗
Yes, I'm a core team member.
kingcauchy · · focus · HN ↗
So for instance because of the size of our codebase our project has pushed Zig to some of the edges, specifically we end up hitting a bug when using llvm and zig on arm64 (Mac and Linux) where it seems to be caused by some configuration Zig passes through to LLVM. I’ve used codex and claude to help me diagnose and find the bug (we use nix’s glibc zig to circumvent the problem now). I now understand the root cause but am not sure what the proper fix would be. But I’ve not known whether or not even raising the issue would break the terms of contributing? Would raising the issue break the implicit agreement?
alexrp · · focus · HN ↗
Regarding whether you should post the root cause analysis: Per the current policy, the answer would have to be no.
I do personally have more nuanced thoughts on this, and I started typing them out... but then I realized that my reply was getting dangerously close to blog post length, so I decided to restrain myself and commit to turning it into an actual blog post later. In a nutshell, though, the problem is that even if there is such a thing as responsible use of LLMs for bug analysis, the only way we can currently be confident that someone possesses the required qualities for that is by working with them for a while.
kingcauchy · · focus · HN ↗
<a href="https://codeberg.org/ziglang/zig/issues/37060" rel="nofollow">https://codeberg.org/ziglang/zig/issues/37060 I opened the issue and can give you the agent generated RCA on the matter if you all want it in issue 604 on antfly's github but I understand that's against policy and totally respect that.
Appreciate all the work you guys do and have been following the whole Zig project since inception fwiw!
tolerance · · focus · HN ↗
ternaryoperator · · focus · HN ↗
tolerance · · focus · HN ↗
kingcauchy · · focus · HN ↗
B4uler5 · · focus · HN ↗
surgical_fire · · focus · HN ↗
Even in projects where I use LLM liberally, I would rather not read or have to engage with your LLM output.
I use LLMs already, I can make do without yours.
sigmar · · focus · HN ↗
I don't want to read LLM output on a project either. But you may have misread the quoted section, it isn't saying "you can't post LLM output," it is saying you can't ask an LLM to advise/critique your own comment before posting it.
>>If you use a chatbot to give you advice on a comment on the issue tracker, that comment is unwelcome.
vips7L · · focus · HN ↗
jibalt · · focus · HN ↗
cabaalis · · focus · HN ↗
I've written code a long time and that's probably the dumbest rule I've seen.
nozzlegear · · focus · HN ↗
throwaway7356 · · focus · HN ↗
phoghed · · focus · HN ↗
miki123211 · · focus · HN ↗
It's clearly a hobby project (constant breakages, the maintainer getting into politics, rejecting some safety mechanisms, the anti-LLM crusade, a strange focus on esoteric targets with little to no commercial significance), but the maintainer does not admit that it is a hobby project.
It makes me respect the Rust community even more.
saghm · · focus · HN ↗
giancarlostoro · · focus · HN ↗
acedTrex · · focus · HN ↗
> gets ignored
Who could have forseen this.
UncleOxidant · · focus · HN ↗
acedTrex · · focus · HN ↗
0c3ca83 · · focus · HN ↗
nvme0n1p1 · · focus · HN ↗
0c3ca83 · · focus · HN ↗
onlyrealcuzzo · · focus · HN ↗
brabel · · focus · HN ↗
boomlinde · · focus · HN ↗
I'm thinking their lives must be absolutely dreadful for this constant fear of being left behind.
doctorpangloss · · focus · HN ↗
senderista · · focus · HN ↗
rererereferred · · focus · HN ↗
bigstrat2003 · · focus · HN ↗
0c3ca83 · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
onlyrealcuzzo · · focus · HN ↗
Typically, any time you think you've found a compiler error, you're using it wrong...
nvme0n1p1 · · focus · HN ↗
Okay: "I compile this input and the linker crashes."
Not okay: "I compile this input and the linker crashes. Also here's 10 paragraphs of slop about dwarf tables, which I can't even evaluate the accuracy of since I'm not an expert."
> Typically, any time you think you've found a compiler error, you're using it wrong...
Yes, if you can't figure out if it's a bug, the bug tracker is the wrong place to get help. Ask in a community forum instead.
onlyrealcuzzo · · focus · HN ↗
It's a 20-line file with a few commands to run it to reproduce it. Not 10 paragraphs of slop.
Presumably that is much more helpful than - here's my gigantic repo, good luck running my tests, also good luck finding the bug.
nvme0n1p1 · · focus · HN ↗
What about my comment made you think I was suggesting not to give repro steps?
> also good luck finding the bug
But yes actually, this half is true. It's better to give them no extra information, than to give too much information that you have no idea if it's true or not.
txdv · · focus · HN ↗