>So because some projects can absorb some PRs of a certain size, all projects of should be able to absorb PRs of that same size?

Your argument has nothing to do with AI and more to do with PR size and 'fire and forget' feature merges. That's what the commenter your responding to is pointing out.

▲

datsci_est_2015 a day ago | parent [-]

And my entire point is that LLM-generated feature requests are strongly correlated with high risk merge requests / pull requests, to which the commenter made no meaningful argument against. Instead the commenter chose to focus on the size of the PR and say “well I’ve seen it in the wild”.

The way to get around this without getting all the LLM influencer bros in an uproar is to come up with a system that allows open source libraries to evaluate the risk of a PR (including the author’s ability to explain wtf the code does) without referencing AI because apparently it’s an easily-triggered community.

	▲	hombre_fatal 2 hours ago \| parent [-]
		Maybe you'll agree with another post I made about how UX/processes already fail us here (without LLMs) and they should be improved: https://news.ycombinator.com/item?id=47324816 I think that's the only shot at progress since it can address the general problem instead of trying to special-case unenforceable rules that you hope the lowest quality people follow. For example, a 3000+ line PR with no communication beforehand is already a low quality PR before AI. And it's one of the most annoying contributions to deal with since you have to basically tell them "sorry but all that work you did isn't acceptable". Yet they probably did all of it in earnest. Presumably you already have a policy where you accept random PRs for small tweaks like doc fixes, but you don't want unsolicited PRs that make substantial changes. So a rule against AI doesn't change anything there. And if you saw an uptick in large unsolicited PRs, then surely the solution is to update the process like disallow PRs that don't link to an issue.