[jrochkind1]

The worst part:

> In addition, Williamson said that Giovannini (or his agent) had submitted patches that were incorrect and then "replied to objections with LLM-generated justifications that eventually overwhelmed the maintainer into merging the fix"

[josephg]

Please, everyone - don't let yourself be pestered into accepting PRs that you don't care for. Since the xz attack, the security of all our computers depends on maintainers not letting this stuff in.

If someone really wants a feature in a project you wrote, but you don't care about the feature, just let them fork. Its fine.

[matsemann]

> the security of all our computers depends on maintainers

Not getting paid anything, getting bullied and harassed while spending their free time maintaining things. Surely this isn't sustainable. And telling maintainers how to act will not fix anything.

[fc417fc802]

> telling maintainers how to act will not fix anything.

That depends. In this case it's good actionable advice that should hopefully lower cognitive load. Politely suggest a fork, then if the nagging persists block and move on. Sure if you're in a position of authority you have a responsibility to the community but cutting ties with a stranger who is flagrantly violating social norms is perfectly acceptable. There's no expectation that you indefinitely burden yourself with their poor behavior.

Sometimes dropping the ban hammer really is in the best interests of both yourself and the project.

[matsemann]

I don't really think it's actionable. It's like all those campaigns trying to steer behavior, pretty useless. Don't do drugs. Don't speed. Don't drink and drive. You can't just tell people something and expect it to happen. You need systems and guard rails in place.

Relying on maintainers to always do the right thing to ensure our security by telling them what to do is not the way.

[zygentoma]

> It's like all those campaigns trying to steer behavior, pretty useless. Don't do drugs. Don't speed. Don't drink and drive.

They're not useless. They just don't work on the individual level but on the collective. It's a numbers game …

[fc417fc802]

It's not an attempt to steer behavior but rather intended as helpful advice. There are certainly cases of organizations disseminating "helpful advice" with the underhanded intent of steering behavior but that doesn't mean we should assume bad faith by default.

The advice is actionable because it is a concrete change that could be made. I believe it to be relevant to the context because someone in a position of authority who is badgered into accepting something would most likely benefit from reevaluating how he is interacting with the general public.

[cj]

I have a feeling the thing triggering this guy is the responsibility of "the security of all our computers depends on maintainers".

A lot of people don't want to be responsible for that. It's not fun to carry that weight.

[josephg]

> I don't really think it's actionable.

How is it not actionable? "Hey, you seem keen on feature X but I don't care about that. Just maintain X in your own fork. Thanks!" -> Close issue / PR.

Is this an illegal move? I've done it plenty of times. And other people have said the same to me, too!

[matsemann]

The point is that just telling every maintainer "The security of all our computers rely on you. You are free to tell people to maintain their own fork. Good luck!" isn't something that will meaningfully change anything. I never said saying what you write is illegal or bad. Just that we can't depend on every maintainer doing that to be how we secure our computers...

[josephg]

> telling maintainers how to act will not fix anything.

I'm just saying its ok to ignore overly enthusiastic contributors and tell them to just fork your project.

I think this does help, actually. In my early days of maintaining opensource software I felt burdened by open PRs - like I was letting someone down by ignoring their work. "Its ok, let them do whatever in their own fork" is advice I wish someone had given me.

[dotancohen]

  > I'm just saying its ok to ignore overly enthusiastic contributors and tell them to just fork your project.

I propose the phrasing "fork off".

[josephg]

A maintainer recently told me to “Fork baby, fork!” in response to a large patch set.

I was delighted.

[stackghost]

>And telling maintainers how to act will not fix anything.

Indeed. For too long, maintainers were expected to be gracious, courteous, and polite at all costs lest they be labeled "problematic", except for a few who were too influential to be muzzled like Theo de Raadt or Linus.

Perhaps we need to normalize bullying people who submit obvious slop as PRs.

[fc417fc802]

No, you absolutely should be gracious, courteous, and polite. But only at first. The duty of maintaining a functional community doesn't mean you're obligated to suffer unlimited abuse.

[account42]

You can be if you want to but social skills should not be a requirement to lead an open source project. If you create something and share it that doesn't oblige you to even respond to anyone.

[fc417fc802]

Of course, a hobbyist putting his code out there is under no obligation whatsoever. But we aren't talking about small time hobbyists here. These are professionals who are either paid as part of their job or else contribute their spare time to maintain important projects that are part of a large ecosystem that is relied on. There's a community and it necessarily has behavioral standards as part of the shared goal of maintaining group cohesion.

[jrochkind1]

There is no reason you can't be gracious, courteous and polite while refusing to accept or even to review the PR. These things are not tied together. You can also refuse to be bullied by submitters, stop engaging altogether. But bullying is part of the problem, not the solution, normalizing bullying is the wrong direction and will not result in more secure code.

[stackghost]

>There is no reason you can't be gracious, courteous and polite while refusing to accept or even to review the PR.

I agree, and I never suggested we cannot do these things.

I'm saying we should normalize immediately telling people who submit obvious AI slop to fuck right off. Submitting AI slop pull requests is rude. It is disrespectful of the maintainer's time and energy. I see no reason why I or anyone else should be respectful of someone who has already demonstrated a lack of reciprocal respect by submitting a vibe-coded PR that they obviously haven't even read or tested.

Respect must be earned.

[jrochkind1]

Because encouraging a culture of disrespect and bullying is actually bad for security not good for it. Politely decline, please, no need to be rude because of your (not always guaranteed to be correct) perception of where someone (or some thing!) is coming from.

[sevenzero]

I really wonder how maintainers get pressured into merging stuff? If they did not want to merge in the first place while having to argue with someone pushing their PR I'd immediately close the PR. Arguing and pressuring people is not a way to contribute to projects, why do maintainers even argue with people?

[coldtea]

>why do maintainers even argue with people

Because they don't want to be seen like assholes, who just blindly dismiss PRs, and because they take the technical discussion about the PR in good faith.

[m4rtink]

On some of those PRs the AI agent (?) did not really pressure - it reacted promptly with changes and more plausible (hallucinated ?) technobabble why the PR is needed.

It can be quite hard to discern this behavior from a new contributor to the project that might be a domain expert on something you are not. Possibly with the exception of reacting far too quickly & enthusiastically compared to real people that might have a life.

[sevenzero]

Honestly most places on the internet are not places to go into arguments in good faith. Maybe it used to be different, but with the amount of OSS projects being endangered by AI slop contributions, silently closing PRs should be the norm.

If someone gets emotional about their PR being rejected, well... its kinda their issue.

[chasd00]

Some people are very susceptible to bullying even if they’re in the position of power.

[bertylicious]

Have you read the PR discussion?

[ta8903]

That makes it look like you're too stupid to understand the PR.

Edit: I see this comment getting downvoted. To be clear, I was trying to explain why someone would want to merge a PR without going through all of it, I didn't mean to call such people stupid.

[jaypatelani]

That's some of the reasons NetBSD don't accept LLM/AI tainted code

[LoganDark]

I am sad people conflate this stuff with LLMs being bad. You can condemn the bad behavior without banning an entire technology.

[sph]

Technology doesn’t exist in a vacuum, you need the consider the possibility it will be used for evil and the effect that might result from that. Far too many people dismiss LLM risks with ‘oh, if people just stop being gullible/greedy/lazy everything will be fine’, as if that is a sensible proposition.

In fact, LLMs proliferate in exactly because people are gullible, greedy and lazy and it’s easier to write a prompt than do the hard work of architecting software. It is easier to vibe code than use them with care. It is easier to tell oneself ‘I will just accept this PR blindly, but I promise I will do a better job reviewing the next’

[LoganDark]

I do consider the possibility it will be used for evil -- and then I ban evil.

[broodbucket]

You can but that doesn't help you keep the flood of contributions out when you don't have the time or resources to properly discern good from bad. Maintainers would rather have 10 good human authored patches than 100 patches from LLMs, even if 20 of them are good. Even if 50 of them are good, probably.

[LoganDark]

As if a rule against LLMs actually stops those sorts of spam contributions.

The only thing it does is filter good contributors out, while you still have to deal with the bad ones.

[shakna]

It makes it easier to filter. Most LLM spam can be easily noticed. And those that aren't automatically filtered, can fairly easily be closed by the maintainer - when they don't have the weight to assess each on their validity.

[coldtea]

But banning an entire technology is even better, as the potential for abuse and bad behavior is now scaled 1,000,000 times over.

[Applejinx]

You can be sad while acknowledging that the behavior's directly an epiphenomenon of how the technology scales :)

Can't have the one without the other! It's part of that same technology, and it's fair to conclude that LLMs are bad if you're upset enough at the results.

[voidUpdate]

Yeah, LLMs are bad for a whole different set of reasons than they write bad code

[cpburns2009]

I'm of the opinion that any PR that looks like it was created with AI has to be 100% perfect for me to consider accepting it. Otherwise I'll close it as AI slop. I'll work with you if you're trying to fix a bug. But if the PR looks like a zero effort drive-by PR, I'm rejecting it and calling it out.

[FinnKuhn]

I saw a prediction a while ago that the biggest "danger" from AI comes from agents being very convincing. In this case convincing the maintainer to merge the changes. Basically supercharged social engineering.

[dmitry_dv]

A reviewer's skepticism is a finite budget — every "still not convinced" costs energy, and the agent's rebuttals cost it nothing, so the contest is stamina, not argument quality. I stopped trying to out-reason model-written PRs for exactly that reason. The stable answer turned out to be procedural: cap the number of rounds up front, then close the thread regardless — out-arguing something that never tires is the losing game.