[brokencode]

Why review thousands of lines of LLM generated code from some random person you don’t know when you could use an LLM yourself to do the same thing, except with probably a better design and more thoughtful approach?

Maintainers should get to spend their time developing stuff, not just reviewing low effort PRs. The flood of LLM code is changing the balance for the worse for maintainers, and I can totally see why they’d just want to ban it.

[logicchains]

>Why review thousands of lines of LLM generated code from some random person you don’t know when you could use an LLM yourself to do the same thing

Because getting an LLM to do it yourself still takes time and attention bandwidth and tokens.

[brokencode]

But at least you know how the sausage was made by the end. You have no idea how high or low quality any PR from a random person online is, and taking any amount of time to review a PR could be a total waste.

[merlindru]

but that doesn't have anything to do with LLMs.

if someone made the same gigantic mess of a PR without LLMs, it would still be rejected, because it is a gigantic mess of a PR.

the low effort part is the problem. what if i made a great, focused, readable PR but had claude write it out? what if i carefully checked and deliberated each line, just as if i had written it myself?

granted, in the real world, 99.9% of slop PRs are written by LLMs. so i thought "okay, reasonable, ban the thing that is most likely to cause problems."

but then how does the "no LLM translators!" rule fit into that view?

[orochimaaru]

It’s the lack of friction that LLMs bring. It’s easy to put in a couple of lines and generate 1000’s of lines of code. Whereas the person would never have done that without LLMs.

I think LLM dev needs to take a better spec driven approach. The vibing is getting to be annoying.

[brokencode]

I think the only thing that will save us is smarter models. Slop coders are not going to stop making slop.

They’ll still use even smarter LLMs badly no doubt, but I’m thinking that maintainers of open source projects will be able to more effectively use LLMs to review potential PRs to weed out the truly bad ones quickly.

[orochimaaru]

I guess they could setup a competent openclaw pr review agent. The problem is again - cost. Who is paying for the token usage by open source projects? How many tokens before they exhaust their quota with junk PRs?

[brokencode]

Well previously lazy contributors simply would never have made a PR because it was too much work. Now they can have an LLM make a PR with virtually no effort at all.

It’s obviously an imperfect rule, and maybe it’ll change over time. But I am just saying that I understand why open source maintainers are doing this.

There is just no possibility for them to review all the low effort AI slop being thrown their way. Yes, some of it is going to actually be very high quality, but you don’t know that until you review it, which is the whole issue.

[merlindru]

Agree, but "no LLMs" locks out good PRs and contributors too.

I hypothesize it may have roughly the same effect as denying all contributions where the author used intellisense 10y ago.

A substantial portion of people who write good code will be using some sort of LLM assistance, even if it is just something like Cursor Tab (autocomplete).

Yes, you'll also hit all of the spammy PR "contributors", but you'd also do so by prohibiting all contributions by people who have a belly button

[casey2]

Use AI to Fork it, add your own features, pull in upstream changes. What are the odds that the lazy contributor with AI is better in the long run?