> 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"
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.
> 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.
> 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.
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.
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.
> 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.
>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.
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.
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.
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.
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.
>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.
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’
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
If you're not going to give Claude access to anything on your machine, why are you using Desktop instead of web chat? (Real question, I don't use these much!)
At least in a corporate environment, Claude Desktop is a pretty decent compromise. Preconfigured internally deployed MCP servers and third-party connectors make many of the necessary integrations relatively easy to control.
I use Claude Code CLI myself (inside a VM, to isolate it from the host) for >90% of my needs. For the remaining fraction - email scours, cloud drive searches, other third-party connections - the desktop application is surprisingly decent. I don't even have more than half a dozen connectors enabled. In the VM I have separate, personally managed access tokens available for various third-party services. Wouldn't really try to maintain more than 5-6, otherwise it gets too confusing. [ß]
The desktop application mostly Just Works[tm] with SSO. At least when M365 doesn't suffer from their 4-times-a-day auth outage.
ß: A lot of APIs and authentication systems were designed in the stone age. You either need a 1:1 permissioned access token that can do horrendous damage, or you deal with ultra-granular, confusing and ill-designed scoping jungle where nothing makes sense. Atlassian, I'm looking at you especially. At least an MCP server, provisioned with a reasonably done service account, doesn't have all of your powers to get things wrong with.
The cloud instance certainly runs a full mitm proxy. There are complications for that when dealing with logging, but maybe on the desktop it doesn't log, just running a permissions engine.
I do use Claude Cowork and hence the VM is important, but I also leave the desktop app running all the time since I have many scheduled tasks at different times. The thing is that the VM could shutdown after being idle for some amount of time and then fire back up when you are ready to use it.
Shouldn't it get swapped out of RAM if it's not being used for a long time? My understanding was that modern memory management is very good at this, there's no need to be shutting idle things down and starting them up all the time. I could be wrong.
This whole thing seems kind of silly to me I must admit. It seems obvious that Claude Desktop needs a VM for security for the majority of it's actual real world use. VM's take up memory, yeah. Them's the breaks. If other competitors have managed to provide as good (or ideally better) security scenario with less RAM, that would be interesting, but just complaining about it seems weird and uninformed to me.
There's such a spectrum between "give it everything" and "give it nothing". Imagine you just want to use it to code and want to make sure any commands it runs doesn't mess up your actual machine.
> this was a regulated monopoly, and if their customer satisfaction dropped below 96% (if I remember correctly) it could result in millions of pounds in fines.
OK, I'm still at the beginning and irrelevant to the article, but as a USA-ian, I am so jealous about that. Unheard of here.
That hit me, too, specifically thinking about my current gas/electricity provider. I have not heard one single piece of positive feedback from the public, and there's only ever problems. I feel like that's a pretty universal experience here. Even outside the scope of websites, it holds so very true.
Personal anecdote: Recently they were updating everyone to "smart meters" on the gas lines. They needed me to be home so they could enter my apartment and bleed the gas out of the line by turning on the stove prior to replacing the meter. I played phone tag with them for 6 months, setting up countless appointments, and nobody ever showed up, the meter remains un-upgraded. At the same time, I have received weekly phone calls and monthly physical letters stating that if I don't upgrade the meter, my gas will be shut off.
I just moved, so the new tenant will have to deal with it now.
The public sector, simple, no frills, accessible, no flashy graphics, websites were a massive eye-opener.
They just worked. They had a job. They did it. I wasn't going to buy more from them because of it, and they didn't care. It was great.
I've heard that recently they've dismantled the centralised team that wrote all the rules, enforced it, and started moving to decentralised hosting, but so far the whole still seems to hold to together really well. I think, I hope, they have embedded the expectation that the local council, the tax office, your visa status, etc, should just be utilitarian in nature, and work for everyone.
I turned off what "glass" UI I could with config, and it's not too different than Sequoia, got used to it pretty quick. Obviously the things not supported on an old OS will keep increasing, until eventually it is EOL'd.
I didn't make any adjustments and hardly ever notice Liquid Glass on macOS. To me, it's only ever noticed if I hang out in the control center/notification center all day.
I think when we look back in 10-20 years, mass nearly universal surveillance will be seen as one of the largest social impacts of AI, or perhaps the largest.
We have barely scratched the surface, and I don't think most people have thought it through.
I guess I appreciate Ellison is educating people about what's going on...
Yeah, LLMs will enable big tech to expand the full surveillance from the online world to the real world, consequently monitoring all aspects of theirs lives.
It's likely gonna take a decade or so for things to become obvious to everyone, just like it took a decade for people to understand the cost of eg. Facebook
Relatively few anyway. Monks (who wrote and edited books and managed libraries, and also taught), artists and musicians, bookkeepers/treasury/exchequer, scribes/chancery (who were the administrators of the kingdoms), and bankers all existed in European "middle ages". But a significantly smaller part of economy/society compared to "western world" now, yes.
Those have been there for a bit, what is more recent is CSS anchor positioning which lets you position the popover near the item that triggered it. It’s all finally very nice!
What would be the point of making up such a story? There isn't one. I live in the same neck of the woods as Charles Stross and see him around occasionally, as well as a few folk that know him. I'm not sure what the big deal with that is? I used to run into Ken MacLeod too sometimes, who is/was a friend of Stross', and in my view a more enjoyable writer. (I've never got into Stross' novels.)
> Relatedly, some federal agencies are discussing the possibility of factoring in geography when they allocate their funds, rather than basing decisions on scientific merit alone.
DEI is about rewarding and punishing people for immutable characteristics like race and sex. Where people live isn't at all immutable, and a government may rightly do stuff to encourage economic activity (like research) in this area vs. another. In fact, they do it all the time.
Having polities to look at promoting regional diversity, equity between regions, and making sure all regions are included, instead of only one axis of "merit", in awarding research funds, is literally DEI.
So it's not that the administration wants them to only look at merit and nothing else, which I thought was the the explanation, but that they think some non-merit things are okay to balance for and try to encourage diveristy, equity, and inclusion on the axis of, and others aren't.
> 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"
reply