Comment by onlyrealcuzzo
7 hours ago
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.
Sounds like you violated the clearly stated project rules and admitted to it. Are you surprised that they're not engaging with you?
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?
It's a violation of project rules to confirm bugs with AI?
Read it yourself: https://ziglang.org/code-of-conduct/
12 replies →
Yes ... pretty damn stupid.
"NO LLMs for finding bugs" is easier written as "Don't use the tools your adversaries will"
I've written code a long time and that's probably the dumbest rule I've seen.
Pointing out something that is not good doesn't require surprise at the fact that it happened
Yeah, the maintainers of a DOA hobby project should certainly be allowed to run it however they want imo
That's honestly my biggest problem with Zig.
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.
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: 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.
1 reply →
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.
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.
4 replies →
The popular LLM projects have infinitely many more bugs than the zig project does this is a ridiculous message.
If it's generating detectably incorrect code, why do you need an LLM to tell you it's a bug?
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.
2 replies →
> breaks the project rules
> gets ignored
Who could have forseen this.
Their policy is immature. Clicking little upvote and downvote buttons is immature. Better to just lie and duplicate the issue.
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.
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.
People keep promising me that I'll be left behind, but somehow it never seems to happen.
They remind me of the "have fun staying poor" people from crypto
2 replies →
They are doing fine, all this "left behind" talk has no basis other than cope.