I don’t usually engage with AI posts on twitter or in general. But honestly this is awesome results by Bun’s team post.
I think it’s the right choice for the Zig team to not upstream AI code. But, can we expect similar patch in the future? What do you think?
Sorry, but how do you know the post or patch has anything to do with AI?
This post at the end of the thread…
That it’s AI code, doesn’t mean we can’t learn from it, and maybe even improve on it.
So yeah, it shouldn’t be upstreamed, but does show there are optimizations out there.
Thank you. Twitter (some call it X) is kind of annoying without an account. I can only see single posts with a direct link. no way to read the thread.
To read the whole thread without an account: https://xcancel.com/bunjavascript/status/2048427636414923250 (replace x.com with xcancel.com)
The ban on AI generated code is misguided if for no other reason than there’s literally no way to enforce it. Anybody with the requisite domain knowledge using these tools can produce high-quality code with none of the obvious smells of vibe-coded slop. Any project with a sufficiently gated contribution process (like ghostty) will be able to iterate and improve much faster than projects that go to great lengths to deny AI-generated code, and people will naturally gravitate to those projects.
Apologies if I am misinterpreting you here, and I’m sure there will be mixed opinions about this, but if a dev who knows enough about software dev and is using AI effectively enough to not make it clear that they’re just doing C-c C-v as you suggest, then I would expect that if that were to come to light, there wouldn’t be some mass revolt against them. I’m sure some would want it, and to be honest, I do not know the stance of the dev team well enough to know how they’d react in that scenario, but all in all, it seems like a pretty easy way to deal with something that has shown to make some projects hellish (not a one-to-one comparison, I know, but you get the idea). You kill 99% of germs, and the remaining ones deserve to be there, so to speak
I’m sure people have said that making a language capable of replacing C and C++ was misguided, too.
You might be right, but this is really just something open source doesn’t have figured out yet. I think the truth is that we just don’t know. Being able to move faster is nice, until it’s at the cost of the sanity of the core team, or if it’s moving faster but then no one has the time and head space to make sure it’s moving in the right direction.
The truth is that most competent developers will respect the “No AI” policy and simply not submit AI-generated PRs. Two examples that come to mind: Mitchell (ghostty) and Jarred (bun).
I think this has nothing to do with AI.
More importantly, it’s whether this patch is truly effective and what its quality is like.
Continuing to discuss whether to introduce AI won’t teach us anything.
This is also a question about licensing. Tons of GPLed(and other viral licensed) code was being used to train LLMs. I doubt the Zig maintainers would like to relicense when eventually a decision falls out of a court case.
I don’t think you are a competent developer if you can’t respect a simple rule, but yeah.
Anybody with the requisite domain knowledge using these tools can produce high-quality code with none of the obvious smells of vibe-coded slop.
That’s a rare exception, IME there are many more examples where people simply switch off their brains and don’t even review the generated code, not to mention thorough testing.
If I were the Zig team I would simply ban large feature contributions from ‘untrusted’ contributors, no matter if written by hand or code-generated via an LLM. Doing a thorough code review for large feature PRs from an ‘untrusted’ author is frankly a waste of everybody’s time. The more the author is trusted (via former contributions), the bigger PRs I would accept from that person.
I would also accept carefully reviewed and curated non-PR issues which point to bugs and performance improvement solutions which had been found by running an LLM-assisted bugscan over the code. Those bugs should have been confirmed and reproduced by a human before writing the ticket (e.g. filtered down to actual issues). E.g. in the case of the Bun project I would expect that they don’t dump a million-lines PR with all the LLM changes, but instead pick those changes apart, isolate the biggest performance contributors, figure out why the performance has improved in that specific place and turn that into one ticket per improvement which is easy to act on by the Zig team.
Running an LLM in “passive mode” (e.g. finding bugs, performance problems, and advicing on solutions) should be much less controversal than letting LLMs write actual code, also from a legal perspective.
I would always require disclosure whether LLM tools had been used though, and tbh outright banning LLM content might be the only option for a popular project like Zig to avoid getting overwhelmed with noise and not being able to pick out the actual signal anymore.
Can’t speak for the Zig team of course, but that’s how I would deal with it.
That’s how the Linux backdoor happened. Like in finance, previous results do not guarantee future results.
That’s where LLMs can be useful as bug scanning / code review tool 
But ultimately, I don’t think there’s a workaround for the concept of ‘trust’ in software development, the alternative would be unhealthy paranoia.
I assume you are referring to the XZ backdoor and Jia Tan, which isn’t the same.
Jia Tan didn’t build cred until they made a larger trusted PR, they built cred to make it easier to become co-maintaner while building up pressuring against the head maintainer — possibly even manufactured the pressure through sockpuppet accounts.
Reputation was important but far from enough, the attack needed several other steps.
To me, the load bearing factor were the expectations from how open source is typically done, there is an entire spectrum of approaches left to be explored. Open source contribution should be more like a community on closer footing — not a seller and client relationship where the product is gratis and tourist issues / PRs are the norm.
Even a minimal reputation system can decrease noise significantly and improve incentive structures.
This is one of those things that’s inherently subject to confirmation bias. There’s tons of vibe-slop engagement bait on social media, high-profile examples where AI coding went wrong does numbers, and incompetent developers (AI assisted or not) vastly outnumber competent ones.
It’s much less interesting and salacious when someone uses these tools in an unremarkable manner, so we rarely hear about it.
AI is entirely besides the point here. The changes in this Zig fork are not desirable to upstream for several reasons.
Parallel semantic analysis has been an explicitly planned feature of the Zig compiler for a long time, and it has heavily influenced the design of the self-hosted Zig compiler. However, implementing this feature correctly has implications not only for the compiler implementation, but for the Zig language itself! Therefore, to implement this feature without an avalanche of bugs and inconsistencies, we need to make language changes.
An example of this is the changes to type resolution which happened in the 0.16.0 release cycle—these didn’t affect users too much, but had big implications for the compiler implementation. Before those changes, the compiler’s behavior was often highly dependent on the order in which types and declarations were semantically analyzed by the compiler. Some orders might result in successful compilation, while others give compile errors. Single-threaded semantic analysis prevented these bugs from causing user-facing non-determinism. The rewritten type resolution semantics were designed to avoid these issues, but Bun’s Zig fork does not incorporate the changes (and has not otherwise solved the design problems), which means their parallelized semantic analysis implementation will exhibit non-deterministic behavior. That’s pretty much a non-starter for most serious developers: you don’t want your compilation to randomly fail with a nonsense error 30% of the time.
Put more simply, we are going to make these enhancements, but hacking them in for a flashy headline isn’t a good outcome for our users. Instead we’re approaching the problem with the care it deserves, so that when we ultimately ship it, we don’t cause regressions.
The other enhancement they discussed is splitting the LLVM backend’s output into multiple modules. There’s nothing wrong with doing this for Debug builds in theory, but it’s simply not the right place for us to focus our efforts. The Tweet showing off this feature showed a compile time of 20 seconds for Bun. However, we view 20 seconds as an entirely unacceptable amount of time to wait for every single rebuild. This change to the LLVM backend has a hard performance ceiling, which Bun’s implementation has probably hit, because there’s no getting around the final bottleneck of LLVM’s compilation speed.
So instead of wasting time writing a more robust implementation of this LLVM module splitting logic for a relatively minor improvement, we have instead put that effort towards features like self-hosted backends and incremental compilation, which can improve compilation speed by orders of magnitude. We can compare the time taken for clean builds of the Zig compiler when using the LLVM backend vs our self-hosted x86_64 backend:
$ zig build --summary new -Dno-lib -Duse-llvm
Build Summary: 4/4 steps succeeded
install success
└─ install zig success
└─ compile exe zig Debug native success 2m MaxRSS:4G
$ zig build --summary new -Dno-lib
Build Summary: 4/4 steps succeeded
install success
└─ install zig success
└─ compile exe zig Debug native success 31s MaxRSS:1G
There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0! (The self-hosted aarch64 backend is unfortunately not stable enough to use yet, but if you’re on aarch64-macos, you can just build for x86_64-macos and run the binaries through Rosetta.)
We can also try using incremental compilation—here’s what it looks like when I run an incremental build of the Zig compiler and then make some random changes to it:
$ zig build --summary new -Dno-lib -fincremental --watch
Build Summary: 4/4 steps succeeded
install success
└─ install zig success
└─ compile exe zig Debug native success 40s
Build Summary: 4/4 steps succeeded
install success
└─ install zig success
└─ compile exe zig Debug native success 361ms
Build Summary: 4/4 steps succeeded
install success
└─ install zig success
└─ compile exe zig Debug native success 368ms
Build Summary: 4/4 steps succeeded
install success
└─ install zig success
└─ compile exe zig Debug native success 371ms
Build Summary: 4/4 steps succeeded
install success
└─ install zig success
└─ compile exe zig Debug native success 172ms
Build Summary: 4/4 steps succeeded
install success
└─ install zig success
└─ compile exe zig Debug native success 308ms
watching 121 directories, 1 processes
Again, this feature is available in Zig 0.16.0—you can use it!
Each update is taking less than 0.4s, compared to the 120+ seconds taken to rebuild with LLVM. In other words, incremental updates are over 300 times faster on this codebase than fresh LLVM builds are. In comparison, an enhancement capped at a 4x improvement is pretty abysmal. To be clear: these numbers are entirely realistic for a big project. I didn’t do things which I knew would be fast, I just made some vaguely-realistic changes. (If you try this on your project and a seemingly-simple incremental update takes more than, like, 0.5s, open an issue! I’m hungry for incremental compilation bugs to fix…)
Put simply, if you’re struggling with compilation speed, please take advantage of the solutions we’ve been working on! The self-hosted x86_64 backend has been the default since 0.15.x, so by upgrading from 0.14.x you automatically get the 4x performance improvement claimed in the Bun team’s post; and incremental compilation can be a night-and-day difference to development loops, particularly when fixing a large number of compilation errors, where you can get an updated list of errors almost instantly.
[EDIT: linkified some text]
This is the kind of level-headed take I’ve come to expect/respect from the compiler team. Thanks for taking the time for a clear reply.