5 ms·

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 6mo 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 6mo ago
  Of course the policy is preventing the merge. That’s literally the point of the policy…
  - lelanthran 6mo 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 6mo ago
      OTOH why bother to polish the PR if it won't get accepted anyway?
      - lelanthran 6mo 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.
        baq 6mo ago
        it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated?
        lelanthran 6mo ago
        > it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated? In this case it looks like the answer is "Yes"; the PR was not dismissed immediately, it was first examined in great detail! Why would the maintainer expend effort on something that was going to be rejected anyway?
        baq 6mo ago
        because the policy is clearly 'reject' and yet significant time has been spent - either effort was wasted or policy is at best 'not implemented'.
        lelanthran 6mo ago
        > either effort was wasted or policy is at best 'not implemented'. I don't understand this PoV - have you ever come across a policy in any environment that wasn't subject to case-by-case exceptions? Even in highly regulated environments (banking/fintech, Insurance, Medical, etc), policies are subject to exceptions and exemptions, done on a case-by-case basis. The notion, in this specific case, that "well they rejected it because of policy" is clearly nonsense and I don't understand why people are pushing this so hard when the explanation of why an exemption can't be made for this specific PR is public, accessible and, I feel, already public knowledge.
        nicoburns 6mo ago
        > it could have been rewritten, rewriting PRs is cheap today Rewriting PRs with LLMs is cheap, but often the output is no better than the previous revision (fixing one issue only to cause another one is very common IME). And reviewing each revision of the PR is not cheap. I've had good experiences with people submitting AI generated PRs who then actually take the time to understand what's going on and fix issues (either by hand or with a targeted LLM generated fix) that are brought up in review. But it's incredibly frustrating when you spend an hour reviewing something only to have someone throw your review comments directly back at the LLM and have it generate something new that requires another hour of review.
      - em-bee 6mo ago
        why bother even contributing anything LLM generated if it won't get accepted?
  - jbxntuehineoh 6mo ago
    > even if are you too stupid to understand the notion of a hypothetical? how did you get on hn in the first place?
    - deleted 6mo ago
      [deleted]
    - daishi55 6mo ago
      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.
- deleted 6mo ago
  [deleted]
- daishi55 6mo ago
  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 6mo ago
    > 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 6mo ago
      Do you think they skipped the main zig test suite or something? Only tested bun compilation? That seems unlikely to me
      - thunderfork 6mo ago
        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.
        zeroonetwothree 6mo ago
        This is the most common issue I see with LLM authored PRs. Yes it does fix the issue _right now_ but as a maintainer I need to consider how it affects the project in the future. But “contributors” get mad if you reject for those reasons. So I can understand having a blanket policy.
  - moregrist 6mo ago
raincole 6mo ago
Because it's Bun. Which is practically the use case testimonial of Zig.
richiebful1 6mo ago
People forget that LLM code cannot be covered by copyright. So LLM code cannot be placed under an open source license
- vehemenz 6mo ago
  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 6mo ago
    > 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 6mo ago
  This opinion does not seem grounded in reality to me.

lelanthran 6mo 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 6mo ago
Of course the policy is preventing the merge. That’s literally the point of the policy…
- lelanthran 6mo 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 6mo ago
    OTOH why bother to polish the PR if it won't get accepted anyway?
    - lelanthran 6mo 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.
      - baq 6mo ago
        it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated?
        lelanthran 6mo ago
        > it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated? In this case it looks like the answer is "Yes"; the PR was not dismissed immediately, it was first examined in great detail! Why would the maintainer expend effort on something that was going to be rejected anyway?
        baq 6mo ago
        because the policy is clearly 'reject' and yet significant time has been spent - either effort was wasted or policy is at best 'not implemented'.
        lelanthran 6mo ago
        > either effort was wasted or policy is at best 'not implemented'. I don't understand this PoV - have you ever come across a policy in any environment that wasn't subject to case-by-case exceptions? Even in highly regulated environments (banking/fintech, Insurance, Medical, etc), policies are subject to exceptions and exemptions, done on a case-by-case basis. The notion, in this specific case, that "well they rejected it because of policy" is clearly nonsense and I don't understand why people are pushing this so hard when the explanation of why an exemption can't be made for this specific PR is public, accessible and, I feel, already public knowledge.
        nicoburns 6mo ago
        > it could have been rewritten, rewriting PRs is cheap today Rewriting PRs with LLMs is cheap, but often the output is no better than the previous revision (fixing one issue only to cause another one is very common IME). And reviewing each revision of the PR is not cheap. I've had good experiences with people submitting AI generated PRs who then actually take the time to understand what's going on and fix issues (either by hand or with a targeted LLM generated fix) that are brought up in review. But it's incredibly frustrating when you spend an hour reviewing something only to have someone throw your review comments directly back at the LLM and have it generate something new that requires another hour of review.
    - em-bee 6mo ago
      why bother even contributing anything LLM generated if it won't get accepted?
- jbxntuehineoh 6mo ago
  > even if are you too stupid to understand the notion of a hypothetical? how did you get on hn in the first place?
  - deleted 6mo ago
    [deleted]
  - daishi55 6mo ago
    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.
deleted 6mo ago
[deleted]
daishi55 6mo ago
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 6mo ago
  > 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 6mo ago
    Do you think they skipped the main zig test suite or something? Only tested bun compilation? That seems unlikely to me
    - thunderfork 6mo ago
      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.
      - zeroonetwothree 6mo ago
        This is the most common issue I see with LLM authored PRs. Yes it does fix the issue _right now_ but as a maintainer I need to consider how it affects the project in the future. But “contributors” get mad if you reject for those reasons. So I can understand having a blanket policy.
- moregrist 6mo ago

raincole 6mo ago

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

richiebful1 6mo ago

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

vehemenz 6mo ago
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 6mo ago
  > 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 6mo ago
This opinion does not seem grounded in reality to me.