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?
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.
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!
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?
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.
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.
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.
Project maintainers know what level of AI use is acceptable for themselves, and quantifying it and enforcing it for random contributors is very difficult.
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.
You also have your book and a wealth of online resources, which also don't require interacting with someone, and which have the same information the AI is trained on. Fundamentally nothing is different. We don't see positive outcomes from students using AI as an aid even if hypothetically it could be possible.
>For most uses the truck is better than the horse.
I think you're talking past the author here, who says:
>By not leaning into LLMs I’ve given myself the room to specialise in a smaller set of skills. So far that conscious decision is working out well, and I remain confident about my job security.
"Most uses" might mean boilerplate and simple frontend work that LLMs can do easily because it's formulaic and doesn't require much creativity. OP is simply not doing that type of work.
I don't think anyone sane is really claiming 100x or 1000x speedups anymore. Most people I talk to who use LLMs are closer to 1.5 or 2. Because their job is not mostly boilerplate, there is simply not that much room to be improved.
It’s not about speed-ups, it’s the fact that I’ll attempt a project far more ambitious than I would have in the past.
Over the past two months I’ve built out a very complex web app for a client. Without the aid of AI it would be far smaller, simpler and less capable. And honestly I probably wouldn’t have agreed to take on the job in the first place.
Sure, in the same way that nano is better than Microsoft Word.
Unfortunately, sometimes nano is not enough.
In the case of this client project, we are only now getting to enough functionality to be generally useful. The complexity that exists in the project is necessary complexity. A lot of coders are simply wrong about complexity, and feel it can always be reduced.
I think that the software world ought to fear and dread complexity, the same way that the Unix designers feared and dreaded verbosity.
«
Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.
»
there's no real difference between an excess of boilerplate and slop.
if your job is just writing boilerplate you're probably doing it badly.
if your app is so simple that really all you need to do is sling boilerplate then it might suffice but it's probably still the most unreliable way to develop that software.
if flakiness, bugginess and unreliability are all fine then yea, boilerplate away.
The "contributor poker" made by someone on the Zig core team is a good one. You're thinking from the perspective like yourself and how they might be affected negatively by this policy. The org is thinking about what's happening at scale and what policy is going to improve outcomes overall for them.
Are there some potential contributors who might be discouraged because of this policy? Probably. Will maintainers have less time wasted by obvious low effort changes and engagement? Also probably. A user of AI is, in the experience of many maintainers, way more likely to be lazy than engaged.
From a marketing perspective, I do not agree. The competitors can claim 100 more features than your "lean" code. That by itself makes you lose customers.
What kind of evidence do you expect beyond "random claims" here?
This post is incredibly obviously AI generated, to the extent that I doubt a human author edited it at all. Not "written with AI assistance" but full on "give Claude some bullets and hit publish." It contains tons of tropes that show up in all AI writing and which people are highlighting here.
As a comparison point, someone decided to try to fix the issues in the Zig original and is now claiming sub-second build times, plus fixed bugs, by modernizing the codebase and sticking with best practices - indicating that all of the issues that justified the rewrite were self-inflicted and addressable.
I have no skin in this game, and the Zig version is also using LLMs if that helps take the culture war out of it. But, it has always been true in my experience that someone who really understands a problem space can outcompete someone who just throws resources (in hundreds of thousands of dollars of token spend) at it.
> indicating that all of the issues that justified the rewrite were self-inflicted and addressable
The main issue that justified the rewrite were memory bugs, especially related to interaction with GC managed Javascript objects. There is no fully general way to prevent those bugs in Zig, and I don't see any claims that they did so in Buz.
They also complained about build times, and in fact the Rust rewrite started immediately after some other drama about Bun being unable to contribute back LLM-written changes to the Zig compiler to improve build times, and the Zig team rejecting them in principle. So while memory issues did become the focus later, I don't think it was the entire story.
Migrating to Rust in a one-to-one translation with unsafe blocks does not make the code any more safe initially. It might provide tools to do a significant refactor that solves lifetime issues with Rust's help, but I haven't seen evidence that they've done that either. They're also embedding a large C++ codebase, JavaScriptCore, so there are always going to be unsafe areas and touchpoints where memory issues could live, and Rust won't magically solve them.
It wasn’t just on principle that those changes were rejected, they also stated the bun changes were not actually that great or general enough to upstream.
> Bun is the quintessential AI slop project at this point. Inheriting that is no easy task. I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape. It will likely require most subsystems to be rewritten.
They're refusing to accept human-authored contributions. They're using LLMs to do the work. The author says they'll use LLMs to de-slop what they think is slop, and humans are banned from contributing.
