It looks like they're spending 5 months what should be a 1 month job these days.
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.
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.
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.
>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
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.
To clarify, do you mean someone who isn't part of the core team?
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?
Yes, I'm a core team member.
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?
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.
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!
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.
I've written code a long time and that's probably the dumbest rule I've seen.
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.
> gets ignored
Who could have forseen this.
Typically, any time you think you've found a compiler error, you're using it wrong...
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.
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.
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.
Unless you're suggesting the language design should also be vibed together?
Sounds like a fun little project, have a bunch of AI pushers fork Zig and see if they can do a better job. I want to see results, not snarky HN comments. After all this progress, ChatGPT should be able to one-shot a better language since AI is so good now... right?
I'm doing it myself: https://zena-lang.dev/
Curious why you wanted a more ML / Rust / Scala inspired syntax. (Personal preference here is totally valid btw, just curious.)
If you're using AI, a language with a large training set is going to win.
Obviously it's not like people are specifically trimming each and every prompt they give a model to tokenmax their models to get the best output / input prompt, we instead live in a spectrum of how many tokens of input and context we're willing to provide to a model to make progress. If the cost of those tokens is low enough for the problem domain you're working in, then it's fine. For some the readability of a personal language may outstrip any of the token costs that one needs to pay to use it. Alternatively maybe you want something like an array language (J, K, APL, etc) which allows array programming and optimizations that conventional PLs just can't do. Maybe you want your language to compile to a target that is highly portable. There's actually a lot of stuff out there that previously wasn't feasible but with LLMs-as-force-multiplier absolutely is.
I also suspect the space is a continuum. There may be pareto optimal points, such as DSLs built atop languages, that are both highly readable but also fairly token efficient.
When I design my own languages (I have written several, all terrible!) it's typically to learn about language design.
I wrote about some of my thoughts with Zena and AI here: https://zena-lang.dev/blog/2026/09/languages-for-the-ai-era/
What is the point of sarcastic, passive aggressive comments like this?
The best I can do is understand its edges and try to find some advantage that leaves me well off enough to stave off the worst effects.
https://mech-lang.org/iros-r4r-2026/index.html#5805406811462...
I compare one algorithm across several programming languages and backends. There is no training data for Mech in the LLM yet it beats most other implementations in perf, which were optimized by LLM.
Maybe human performance engineers trained in these languages could write better implementations. But to answer the question of whether the LLM could write more performant code in languages it’s trained in versus languages it’s not, this comparison is at least illustartive.
Not necessarily? What if the training set contains an overwhelming amount if bad code written by neophytes? I imagine Python quality by the LLM suffers from this, for example.
What if the language has extremely confusing syntax constructs (like early php) or bad or no conventions (suppose the standard library has somecollection.put(key, value) sometimes and othercollection.put(value, key) other times), and individual code authors just pick what they want adhoc
Large training set ain't gonna save you.
None of these systems can. They need enormous training. They need alignment and reinforcement. They need harnesses. And most importantly they need a human that knows how to write and develop a C compiler.
The ISO specifications are not sufficient. Neither are the System V guidelines. Not even spec tests and compcert.