Thread

1. zzzeek · 1791054135 · focus · HN ↗

   banning AI from PRs because you're swamped with too many low quality PRs, definitely. We pretty much are doing this with SQLAlchemy. If I'm going to have a small fix or improvement coded by an LLM (which I do all the time), I want to prompt the LLM directly, rather than having someone trying to pad their resume forward my communications onto their LLM via PRs. What's the point of that?

   1. nonethewiser · 1791054331 · focus · HN ↗

      > If I'm going to have a small fix or improvement coded by an LLM (which I do all the time), I want to prompt the LLM directly, rather than having someone trying to pad their resume forward my communications onto their LLM via PRs. What's the point of that?

      Which is why LLM PRs should just be issues (if there isn’t one already). Make the issue author a co-author on the PR. But let the maintainer actually oversee the LLM generated solution.

   2. api · 1791054788 · focus · HN ↗

      Maybe the policy should be: no AI PRs except from established contributors who have been vetted?

      So basically you're saying you reject drive-by PRs.

      1. whateveracct · 1791055772 · focus · HN ↗

         drive-by PRs that are handwritten are presumably okay
   3. nicoburns · 1791057120 · focus · HN ↗

      Reasonable, although I've taken a different approach. Either closing such PRs, or treating them as very detailed issues and having my own LLM build the actual fix.

      My repos probably don't see as much traffic as SQLAlchemy though.

   4. baq · 1791057685 · focus · HN ↗

      rejecting low quality ones should be the norm regardless of whether an AI or a human wrote them. the question is what would happen if you were swamped with high quality PRs? what will happen once you are? (that's probably a 2027 question!)

      1. grumbel · 1791062065 · focus · HN ↗

         I'd still reject them. It's the bug reports and feature requests that are valuable. When you have an AI yourself, there is little point in having somebody else let their AI implement them, that just creates a lot of risks and unknowns for no benefit.
      2. zzzeek · 1791069073 · focus · HN ↗

         yeah a lot of LLM PRs are pretty good, but still need changes, and still didnt come from my own prompting which would have got them more exactly where I want them, so it's again, I have to put messages on a PR and wait for someone somewhere to see them and act on them. That friction is a huge waste of time if they're just prompting their own robot. I have the same robot right here and I usually use opus 5.x which is usually better than what they're using.

         1. baq · 1791116600 · focus · HN ↗

            I think it’s perfectly ok to just tell your robot how to get a good pr to a state you like and merge it then. You should of course let folks know that this is the policy, but ultimately if it solves their problem the way you like it and you didn’t have to spend your tokens on it everybody wins…?

            1. zzzeek · 1791121526 · focus · HN ↗

               i use claude max and ive yet to get even 30% into my quota for it. so as long as that kind of deal lasts i dont think much about tokens.

               if i did have to think about tokens I use something like together.ai with an open weight model like glm 5.3 (which ill sometimes use to review a claude change for something intricate). glm 5.x is just very chatty though

Unofficial Hacker News client; not affiliated with Y Combinator.