[hitekker]

Apparently, the noise around the AI policy came from Bun's developers saying that policy blocks upstreaming their performance PR. But the real reason seems to be that PR's code itself isn't in great shape, and introduces unhealthy complexity https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

> 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.

[adrian_b]

Yes, that reply provides convincing arguments for not merging the Bun fork, as it interferes with Zig's own roadmap for achieving even better results, while continuing to improve the whole language.

[kunley]

Not only this, but also:

Bun's fork will exhibit indeterministic behavior.

[dalmo3]

As if that was a bad thing in 2026!

[DonaldPShimoda]

...why does it being 2026 make nondeterminism more desirable or reasonable?

[easton]

It’s a joke because all of the AI systems du jour are non deterministic and people are putting them in important places anyway.

[Krssst]

This was probably a joke about a lot of developers delegating coding to LLMs which are usually non-deterministic (which I personally think is less of an issue than LLMs not having specified behavior like programming languages do).

[bonzini]

A single PR for a 3000-line addition would, in all likelihood, be rejected anyway.

[dgellow]

Really depends the author and context. Large PRs are often justified for compiler work, you have a lot of pieces to touch at the same time

[jeffmess]

Doubt it: https://github.com/ziglang/zig/pull/24536

[omnimus]

When somebody comments PR with “Incredible work, Jacob. It is an honor to call you my colleague.” then it's safe to assume it's out of the ordinary contribution. Pretty much falling outside of the “in all likelyhood”.

3000 line LLM commit is not that.

[defmacr0]

Also 95% of those 30k lines changed are fully self-contained inside of the aarch64 directory and of the remaining changes it looks like the majority is just adding "aarch64" as another item into an existing list. There are a few core changes that to me look like they could be done in their own PRs, but also core maintainers get to decide if they want to apply bureaucracy to their own work.

[thomascountz]

No description provided. I love this PR. But yeah, try being anyone besides Jacob and submitting that!

[KronisLV]

> In successful open source projects you eventually reach a point where you start getting more PRs than what you’re capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don’t do this just because it’s the “right” thing to do, but also because it’s the smart thing to do.

I feel like if their goal is to prioritize contributors over contributions, it'd also logically follow that they should try to have descriptions where possible? Just to make exploring any set of changes and learning easier? Looked it over briefly, no Markdown or similar doc changes there either.

I mean the changes can be amazing, it's just that adding some description of what they are in more detail, alongside the considerations during development, for new folks or anyone wanting to learn from good code would also be due diligence.

[vga1]

How would you differentiate a 3000 line LLM commit made by the best models and good AI processes from a 3000 line commit made by the best human developer?

edit Okay, I set the bar too high here with "best human developer" and vague "good AI processes". My bad. Yes, LLM is not quite there yet.

[vurudlxtyt]

A personal relationship and trust, as seems to be the case here?

[wiseowise]

By using my brain.

[dnikolovv]

Don't be ridiculous! We don't do that anymore.

[saagarjha]

Read it?

[IshKebab]

It's still fairly obvious just by skimming the code. The best AI models are still quite far from the best human developers in ability and especially in code quality.

[matwood]

When the best AI models are the same or better than the best[1] human developers, what then?

We're already at the point talking about best vs. best.

[maccard]

The post that inspired this post [0] says:

> So while one could in theory be a valid contributor that makes use of LLMs, from the perspective of contributor poker it’s simply irrational for us to bet on LLM users while there’s a huge pool of other contributors that don’t present this risk factor.

> The people who remarked on how it’s impossible to know if a contribution comes from an LLM or not have completely missed the point of this policy and are clearly unaware of contributor poker.

The point isn't about the 3000 line PR, it's about do we think the submitter is going to stick around.

[0] https://kristoff.it/blog/contributor-poker-and-ai/

[PunchyHamster]

It seems to be trivially easy for everyone but people heavily invested into LLM to spot LLM slop

[flohofwoe]

Jacob is part of the core team, not a random outside contributor.

[slekker]

Very different context: that PR is from a maintainer, and trusted member of Zig, which surely discussed the implementation/design internally as well

[daishi55]

What’s the point in debating the PR quality? The policy explicitly forbids all LLM code, so that policy is of course the “real reason”.

[lelanthran]

> What’s the point in debating the PR quality?

Because the pro-group are whining that the policy is preventing the merge, when in actual fact even if the policy did not exist, the PR is crap anyway.

[daishi55]

I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. But regardless, let’s say it’s a bad PR for the sake of argument - it’s beside the point. It cannot be merged no matter how good it is, due to the strict no-LLM policy.

[greggyb]

> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig.

That may be the case, but the bun project only needs zig to correctly compile bun. The zig project needs to be able to correctly compile all existing and possible zig programs.

I haven't reviewed things, but it's possible and even likely (at least based on my own experience with LLMs) that the validation is mostly focused on bun compilation.

[daishi55]

Do you think they skipped the main zig test suite or something? Only tested bun compilation? That seems unlikely to me

[thunderfork]

They didn't take into account the long-run impacts of the changes on future development, etc.

I recommend reading the explanation given by one of the Zig devs, as it's a very clear and solid one.

[moregrist]

> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig.

The PR is probably fine for bun’s purposes. That doesn’t make it a good PR for Zig’s purposes, and could very well paint Zig into a weird corner.

> It cannot be merged no matter how good it is, due to the strict no-LLM policy.

This is about meta-discourse. Of course it’s against the policy. That’s the point of discussing the PR: to get Zig to change the policy, or at least provide an exception in this case. Or to argue the opposite.

[Aeolun]

Of course the policy is preventing the merge. That’s literally the point of the policy…

[lelanthran]

> Of course the policy is preventing the merge. That’s literally the point of the policy…

In this case it isn't the blocker - the fact that the dev took the time to read the PR in detail, comment on it, and provide reasons why it could not be merged makes it very clear to me that the policy wasn't the blocker.

If they were going to enforce the policy for this PR, they wouldn't have bothered to read it. The only reason to read it is to see if the policy is waived for this specific PR.

[baq]

OTOH why bother to polish the PR if it won't get accepted anyway?

[lelanthran]

> OTOH why bother to polish the PR if it won't get accepted anyway?

As the Zig maintainer so patiently explained, no amount of "polish" can fix the PR because it is misaligned to the correctness that they require.

IOW, that PR is so far off the reservation, unless it is completely rewritten, it won't be accepted.

[em-bee]

why bother even contributing anything LLM generated if it won't get accepted?

[jbxntuehineoh]

> even if

are you too stupid to understand the notion of a hypothetical? how did you get on hn in the first place?

[daishi55]

The point we are making is that in reality, it is the policy which is preventing the merge. Sure, in your hypothetical, maybe it couldn’t be merged anyway. But while the policy exists, the hypothetical is irrelevant. The policy is preventing the merge.

You also don’t sound smart enough to be calling others stupid.

[richiebful1]

People forget that LLM code cannot be covered by copyright. So LLM code cannot be placed under an open source license

[vehemenz]

This is overstated. Not all LLM code is produced the same way. Code produced through substantial human creative input still falls under copyright, at least the way things are now. Besides, nothing legally prevents placing code under a license. Enforceability is the question, not permission.

It's a bit like saying speed limits don't apply on private property, therefore you can't have any traffic rules on your private racetrack.

[acdha]

> Besides, nothing legally prevents placing code under a license. Enforceability is the question, not permission.

That’s not how copyright works. If you don’t own the code, you can’t release it under a license. The question of how much human editing is needed to establish copyright is a huge question right now.

[daishi55]

This opinion does not seem grounded in reality to me.

[raincole]

Because it's Bun. Which is practically the use case testimonial of Zig.