5 ms·

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 b

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-compilation-times/15183/18?u=andrewrk 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.

bonzini 5mo ago
A single PR for a 3000-line addition would, in all likelihood, be rejected anyway.
- jeffmess 5mo ago
  Doubt it: https://github.com/ziglang/zig/pull/24536 https://github.com/ziglang/zig/pull/24536
  - omnimus 5mo ago
    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.
    - vga1 5mo ago
      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.
      - saagarjha 5mo ago
        Read it?
        deleted 5mo ago
        [deleted]
      - vurudlxtyt 5mo ago
        A personal relationship and trust, as seems to be the case here?
        deleted 5mo ago
        [deleted]
      - IshKebab 5mo ago
        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 5mo ago
        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.
        IshKebab 5mo ago
        If that happens and we have a way of reliably knowing if some code is produced to that high quality, then I think we probably can accept that AI coding is the only sensible option. We definitely are not close to that point though and it's unclear if/when we will get there.
        vga1 5mo ago
        It seems to me that people might be arguing from conflicting hidden premises here. "AI Coding" is a spectrum that could mean something as simple as letting the LLM proofread your changes and then act on those with your own human brain, or it could mean just telling the agent what you want and let it rip and tear until it is done. If I do the latter and submit a PR to something like Zig, I'll be certainly caught doing it and rightfully chastised. If I do the former, my PR will be better without anybody besides myself having any way of knowing how it got better. Probably I do something in between when I contribute to open-source these days. Blanket banning all of these seems like a bad idea to me. It actively gates people like myself from contributing, because I respect these people and projects that much. It feels like I would be doing something they find disgusting if my work has touched an LLM and I obviously don't want to do that to people I respect. But it's fine, there are plenty of things to do in the world even when some doors are closed. I do not presume to have any say on Zig project's well argued decisions[0] -- I'm not really even their user let alone someone important like a contributor. Their point of preferring human contact is superb, frankly. Probably a different kind of problem in an open-source project staffed with a lot of remote working people, where human contact is scarce. https://kristoff.it/blog/contributor-poker-and-ai/ https://kristoff.it/blog/contributor-poker-and-ai/
    - thomascountz 5mo ago
      No description provided. I love this PR. But yeah, try being anyone besides Jacob and submitting that!
      - KronisLV 5mo ago
        > 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.
    - defmacr0 5mo ago
      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.
  - slekker 5mo ago
    Very different context: that PR is from a maintainer, and trusted member of Zig, which surely discussed the implementation/design internally as well
  - flohofwoe 5mo ago
    Jacob is part of the core team, not a random outside contributor.
- dgellow 5mo ago
  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
daishi55 5mo ago
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 5mo ago
  > 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.
  - Aeolun 5mo ago
    Of course the policy is preventing the merge. That’s literally the point of the policy…
    - lelanthran 5mo ago
      > 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 5mo ago
        OTOH why bother to polish the PR if it won't get accepted anyway?
        lelanthran 5mo ago
        > 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.
adrian_b 5mo ago
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 5mo ago
  Not only this, but also: Bun's fork will exhibit indeterministic behavior.
  - dalmo3 5mo ago
    As if that was a bad thing in 2026!
    - DonaldPShimoda 5mo ago
      ...why does it being 2026 make nondeterminism more desirable or reasonable?
      - easton 5mo ago
        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 5mo ago
        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 5mo ago

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

jeffmess 5mo ago
Doubt it: https://github.com/ziglang/zig/pull/24536 https://github.com/ziglang/zig/pull/24536
- omnimus 5mo ago
  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.
  - vga1 5mo ago
    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.
    - saagarjha 5mo ago
      Read it?
      - deleted 5mo ago
        [deleted]
    - vurudlxtyt 5mo ago
      A personal relationship and trust, as seems to be the case here?
      - deleted 5mo ago
        [deleted]
    - IshKebab 5mo ago
      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 5mo ago
        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.
        IshKebab 5mo ago
        If that happens and we have a way of reliably knowing if some code is produced to that high quality, then I think we probably can accept that AI coding is the only sensible option. We definitely are not close to that point though and it's unclear if/when we will get there.
        vga1 5mo ago
        It seems to me that people might be arguing from conflicting hidden premises here. "AI Coding" is a spectrum that could mean something as simple as letting the LLM proofread your changes and then act on those with your own human brain, or it could mean just telling the agent what you want and let it rip and tear until it is done. If I do the latter and submit a PR to something like Zig, I'll be certainly caught doing it and rightfully chastised. If I do the former, my PR will be better without anybody besides myself having any way of knowing how it got better. Probably I do something in between when I contribute to open-source these days. Blanket banning all of these seems like a bad idea to me. It actively gates people like myself from contributing, because I respect these people and projects that much. It feels like I would be doing something they find disgusting if my work has touched an LLM and I obviously don't want to do that to people I respect. But it's fine, there are plenty of things to do in the world even when some doors are closed. I do not presume to have any say on Zig project's well argued decisions[0] -- I'm not really even their user let alone someone important like a contributor. Their point of preferring human contact is superb, frankly. Probably a different kind of problem in an open-source project staffed with a lot of remote working people, where human contact is scarce. https://kristoff.it/blog/contributor-poker-and-ai/ https://kristoff.it/blog/contributor-poker-and-ai/
  - thomascountz 5mo ago
    No description provided. I love this PR. But yeah, try being anyone besides Jacob and submitting that!
    - KronisLV 5mo ago
      > 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.
  - defmacr0 5mo ago
    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.
- slekker 5mo ago
  Very different context: that PR is from a maintainer, and trusted member of Zig, which surely discussed the implementation/design internally as well
- flohofwoe 5mo ago
  Jacob is part of the core team, not a random outside contributor.
dgellow 5mo ago
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

daishi55 5mo ago

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 5mo ago
> 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.
- Aeolun 5mo ago
  Of course the policy is preventing the merge. That’s literally the point of the policy…
  - lelanthran 5mo ago
    > 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 5mo ago
      OTOH why bother to polish the PR if it won't get accepted anyway?
      - lelanthran 5mo ago
        > 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.

adrian_b 5mo ago

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 5mo ago
Not only this, but also: Bun's fork will exhibit indeterministic behavior.
- dalmo3 5mo ago
  As if that was a bad thing in 2026!
  - DonaldPShimoda 5mo ago
    ...why does it being 2026 make nondeterminism more desirable or reasonable?
    - easton 5mo ago
      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 5mo ago
      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).