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 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.
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.
I'm thinking their lives must be absolutely dreadful for this constant fear of being left behind.
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.
Note the LLMs are trained on language semantics far beyond the mainstream ones, so language design can become quite exotic without straying too much from the training. You really do have to measure these things, I don’t see how you can make a confident assertion without data.
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.
At work I use Claude, but it is a considerably larger and quite complex codebase. I use LLMs a lot, but it is a common weekly occurrence for me to correct misconceptions, bugs, or overengineering from Opus/Sonnet (Opus plans and reviews, Sonnet implements).
Thanks for your work btw.
https://youtu.be/zwi5b5xSsKA?is=PTjJJjSnVMdRuZag
It may surprise some people here to see that Andrew is warming up to using LLMs to discover bugs (inspired by results from SQLlite) and considers it a tool on the path to getting to bug free software.
Someone in the thread below says their bug was closed because of mentioning that they use AI to confirm the bug they had encountered. Is he going to go back and reopen all of those now that he learned what pretty much everyone else already knew?
I don't know about this particular case, but if I saw someone report a bug and as evidence claim they had X Y and Z LLMs verify it I would be pretty upset. If you're going to use an LLM to make a replication, just do that and give me the replication, don't point to your notoriously error-prone tools as though they lend your report credence.
It's in a similar vein to people who reply to questions with "well Claude says: <chat transcript dump>"
or substantially worse: "<chat transcript dump>"
If a report is improved and becomes actionable, that's great.
That you used an LLM to "confirm" the bug is an example of such non-information. The reproduction testcase and/or the reproduction steps and description of the expected outcome confirm the bug.
Bug fixes should get the same treatment. A patch is either correct or it isn't. Projects that ban AI-written fixes outright are asking "who wrote this?" instead of "is this right?", and users live with the bug in the meantime.
I get why maintainers are fed up. Review time is scarce, and they're drowning in plausible-looking garbage. But that's a problem with low-quality submissions, not with AI as such. Require tests, require a human who vouches for the patch and will answer for it, and ban repeat offenders. Then hold every patch to that same bar, whoever or whatever wrote it.
In the state of the tagged video he says still not accepting AI submissions until a certain set of preconditions is met. So... No?
- using the LLM to find (possible) bugs and a human confirms it by testing, reviewing, etc.
- using the LLM to find and confirm the bug without the human confirming it
> that I had every LLM check it to confirm it's a bug
I'm primarily objecting the way he phrased it, as opposed to just saying "I've tested and confirmed and reproduced the bugs". Instead, it sounds uncertain and detached, like he asked the LLMs if it's indeed a bug without further verification.
Just don't be surprised if the project BFDL talks shit about you or your company later.
(Still a good language though, credit where credit is due.)
A simple, "this entity is a sponsor, and therefore there is a conflict of interest and we will not comment on recent controversy" is enough.
If it's big enough, refuse to take further contributions.
I know it's not entertaining, but that's why we have video games.
For some reason--COVID brain rot, poorly-socialized people coming online, general increase in viciousness in the population, who knows!--people have forgotten the utility and purpose of boring polite manners and communication.
I'm looking forward to see what the new build integration can unlock on the tooling side.
What I'm looking for the most for the next release(s):
- New stackless coroutine IO implementation
- First class fuzzer tooling
Outcompetes C even? I'm especially exited for SpirV. Would be great to use Zig for both CPU and GPU programming.
Especially in WebGPU, where WGSL tooling is very early.
It’s not for everyone yet. It’s still unstable, and its ecosystem is small. However, both are improving.
- wasm lalign utility (integrated in opengenepool.vidalalabs.com, not obvious how to trigger it but you can inspect the wasm package)
- real-time DNA gel lane assignment
- proprietary (Claude also used zig to reverse engineer the usb wire protocol) industrial camera driver
Last two:
https://x.com/DNAutics/status/2099583335940936175?s=20
If you want weirder shit:
To be fair, I've heard this for years now, yet the hype keeps mounting. I wasted half an hour this morning debugging a broken Zig project, all because I used a release a few months too new that removed some options used in build.zig
Releasing stable software and caring about backward compatibility is a skill many open-source maintainers don't ever want to engage with. It's so easy saying "our code is not stable, if it breaks good luck to you", but at some point it starts to smell like fear of commitment to running a serious project that people depend on.
For comparison, Elixir started in 2012, and got its 1.0 in 2014, two years later. Zig stable has been ‘a few years’ for literally a decade.
Background is I created issue and one pull request to fix them in zig compiler version 0.16.1 issue numbers 36812, 36811 (you cannot access them as my account is banned can see my fork at [2]). Respecting the community’s no AI stand. For these specific issues I wrote the issue and code myself and not let AI write it. Spend a lot of time on it. Subsequently without any notice my account was banned because my projects on github using zig uses LLM. This was done without message or any information. My account was banned on zig repository.
I can now understand the other side of coin how bun team might have been treated with disdain when they used LLM.
I wrote an email and left the zig community, have many work in zig but slowly moving them to odin.
I feel personal disdain should not be spilled on to people who are pragmatic on using LLM. I was a very big evangelist of zig for their no LLM stand and promoted them among my community, but with poor treatment by community I just left. You can still see projects I wrote in zig [3].
I have worked with postgreql community since 1997 and python community since 1998. Never felt such hostile community. So all the best and I wish zig continue its progress
[1] https://github.com/insanai/sqlodin
I have been in open source world with linux kernel since 1992, never every had seen a community so hostile, especially towards humans who spend time and efforts just out of curiosity, inquisitiveness and trying to support some simple alternative when odds are already against them.
Facing hostile behavior from inside the community made me switch to odin language where they also do not use LLM but are pragmatic about people using it. Cannot comment on Mitchell because I do not contribute with money.
> my account was banned because my projects on github using zig uses LLM.
Its not Zig. Its codeberg. Codeberg has a strict no-AI policy. Codeberg is ALL about the community and not the lone hacker. I think its a good policy to prevent overload and clearly distinguish project ecosystems from each other.
https://blog.codeberg.org/protecting-our-floss-commons-from-...
To be clear, we do not block people for merely having LLM-related projects. Obviously we have opinions about LLMs in a broader context, but in terms of rules enforcement, we only care about LLM usage taking place within official Zig spaces.
It's possible you were blocked in error. LLM detection is not foolproof, so unless it's an open-and-shut case, our usual approach is to just unblock if people reach out to us by email.
Who did you email, when, and did you get a response? We've all been very busy leading up to the release, and most of the team is also currently traveling for SYCL.
Regarding sending a message, consider our side: We're tired of having our time wasted on slop, so we don't also want to have to write formal block notifications to people we block on suspicion of using LLMs. I'm fully aware that this can lead to an unfortunate situation like this, however. For what it's worth, this is why we want to move to an invite tree for Zig development; it'll allow us to create a high-trust environment where this kind of suspicion is unnecessary.
I wish all the success to zig because diversity keeps the innovation alive.
The reason I moved on is, after 2 times consecutively facing the same issue, I felt I will be helpless in zig community and felt like my voice will be muzzled without any reason done in an opaque and abrupt manner. I prefer to err on the side of openness than caution.
Sorry, would you mind clarifying what you mean by this? I'm only aware of the one incident?
"Jarred was already writing slop well before he had access to LLMs."
"Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show"
"When Jarred announced the Rust rewrite, we were ecstatic. It seemed too good to be true. I have to admit, I didn't think the technology was there, to pull off this stunt. But he did it, and now I'm metaphorically sipping delicious tea from a mug that says "It Tastes Like It's Not My Problem Anymore"." [1]
or what about when he called people "monkeys" because he didn't like their product [2]
or when their vp of "community" called github employees clowns [3]
so don't let people tell you that there isn't a pattern here. and when this kind of behaviour comes from the top it shapes the rest of the community
[2] https://web.archive.org/web/20251127021007/https://ziglang.o...
> Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show
Are these claims false, though?
What's this new approach they're trying?
Once that is done, @dnautics is working on memory safety for zig [1]. A Checker for Lifetimes and other Refinement types.
Then we can start the Rust vs Zig Debate again. Hopefully not too late.
Either Zig gets good enough to be a worthy re-write target, or it doesn't. But I suspect that isn't even what they want.
I imagine languages are going to bifurcate into ones that go all in on agent experience and ones that go all in on human experience. And Zig seems to be in the latter group. I am confident that there will always be some niche market for languages lovingly crafted for humans. But the criteria we will use to define success within these groups of languages will be different.