Very reasonable stance. I see reviewing and accepting a PR is a question of trust - you trust the submitter to have done the most he can for the PR to be correct and useful.

Something might be required now as some people might think that just asking an LLM is "the most he can done", but it's not about using AI it's about being aware and responsible about using it.

▲

rustyhancock a day ago | parent | next [-]

Important though we generally assume few bad actors.

But like the XZ attack, we kind of have to assume that advanced perissitant threats are a reality for FOSS too.

I can envisage a Sybil attack where several seemingly disaparate contributors are actually one actor building a backdoor.

Right now we have a disparity in that many contributors can use LLMs but the recieving projects aren't able to review them as effectively with LLMs.

LLM generated content often (perhaps by definition) seems acceptable to LLMs. This is the critical issue.

If we had means of effectively assessing PRs objectively that would make this moot.

I wonder if those is a whole new class of issue. Is judging a PR harder than making one? It seems so right now

▲

nokcha 2 hours ago | parent | next [-]

> LLM generated content often (perhaps by definition) seems acceptable to LLMs.

In my experience (albeit with non-coding questions), ChatGPT 5.2 is often quite eager to critique snippets of its own replies from previous conversations. And reasoning models can definitely find flaws in LLM-written code.

▲

vladms a day ago | parent | prev [-]

> Is judging a PR harder than making one?

Depends on the assumptions. If you assume good intent of the submitter and you spend time to explain what he should improve, why something is not good, etc, than it's a lot of effort. If you assume bad intent, you can just reject with something like "too large review from unproven user, please contribute something smaller first".

Yes, we might need to take things a bit slower, and build relations to the people you collaborate with in order to have some trust (this can also be attacked, but this was already possible).

	▲	PowerfulWizard a day ago \| parent [-]
		On judging vs. making, also someone has to take time away from development to do code review. If the code being reviewed is written by someone who is involved and interested then at least there's a benefit to training and consensus building in discussing the code and the project in the review phase. The time and energy of developers who are qualified to review is quite possibly the bottleneck on development speed too so wasting review time will slow down development. For AI generated code if previous PRs aren't loaded into context then there's no lasting benefit from the time taken to review and it's blank slate each time. I think ultimately it can be solved with workflow changes (i.e. AI written code should be attributed to the AI in VCS, the full trace and manual edits should be visible for review, all human input prompts to the AI should be browsable during review without having scroll 10k lines of AI reasoning.)

▲

delichon a day ago | parent | prev | next [-]

> I see reviewing and accepting a PR is a question of trust

I think that's backwards, at least as far as accepting a PR. Better that all code is reviewed as if it is probably a carefully thought out Trojan horse from a dedicated enemy until proven otherwise.

	▲	bigfishrunning 19 hours ago \| parent [-]
		I think this is actually a healthy stance. If you want to maintain patches against a project, just maintain a fork the project and if I want to pull in your changes I will. No direct submissions accepted is not the worst policy I think

▲

veunes a day ago | parent | prev | next [-]

I think framing it as a trust question is exactly right

▲

jajuuka a day ago | parent | prev [-]

That's the key part in all this. Reviewing PR needs to be a rock solid process that can catch errors. Human or AI generated.