What is it about LLMs that makes so many devs' brains melt?
this post was submitted on 31 May 2026
1088 points (98.1% liked)
Fuck AI
7568 readers
821 users here now
"We did it, Patrick! We made a technological breakthrough!"
A place for all those who loathe AI to discuss things, post articles, and ridicule the AI hype. Proud supporter of working people. And proud booer of SXSW 2024.
AI, in this case, refers to LLMs, GPT technology, and anything listed as "AI" meant to increase market valuations.
founded 2 years ago
MODERATORS
Studies have already shown that the moment you start relegating code to LLMs you kinda just start using them as a crutch even if you don’t need them.
Staff Engineer here. Our CTO told us in March two things. One, if we didn't get on board with AI then we would be unemployable in 3 months and two, we had to use AI for everything. Literally everything. I asked (as a senior engineer of 19 years) if that included simple bug fixes I see that take minutes vs 30+ describing the problem. The answer was "absolutely". Our budget is $400K /month to Anthropic and we exceeded that 3 weeks into May
Update on this: those people who didn't incorporate it into their workflow have been let go. Last night they released 1/6th of the staff.
Pump those numbers, make them regret the decision.
Also that’s an insane budget for AI.
Our budget is $400K /month to Anthropic and we exceeded that 3 weeks into May
Fucking hell, that's so much money to burn on management's AI addiction. Have to wonder how your finance department feels about burning almost half a million a month.
Also, wild that management is telling you that not letting your skills degrade by handing everything off to an AI is what'll make you unemployable.
They think once the ball is rolling, then they can phase out the humans.
They think that AI usage is like training a junior dev, that it starts out hopeless but over time can operate without the expertise.
They don't realize that invoking AI doesn't work that way, that the context window is the only accumulation of anything germain to your codebase, and that the model doesn't evolve based on that interaction.
So they don't care about the skills, they want to get to the point where they can toss a prompt into Claude and have it all taken care of, thinking that their employee usage of it somehow accelerates that outcome.
load more comments
(1 replies)
Burn that budget. Make the CFO pull their hair out when they look at expenses vs revenue. For once, bean counters might save us from this BS.
If they're anything like my company's executive team, they're using AI to make their decisions too. They're being spoonfed the issue isn't AI underperforming, it's you.
They'll soon fire you first before capitulate on the notion their AI implementation sucks.
load more comments
(3 replies)
400k a month is quite a bit of GPU power. I do not understand why software companies aren't at least offsetting their Claude usage with open source models running on their own hardware. It seems like a no brainer. Opus is really good but most tasks aren't that complex and a smaller model will work just as well.
Sometimes I'm sad I quit software development as a job. So much room for malicious compliance with this AI bullshit. And if something goes wrong you can just blame it on the AI you were forced to use. The fun I could have had..
load more comments
(1 replies)
load more comments
(4 replies)
People lazy.
Here it seems like panic in the face of things like the CopyFail/DirtyFrag/Fragnesia/ssh-keysign-pwn stuff.
That if he didn't let AI 'fix' the issues it can find first, then someone will hit rsync with devastating CVEs.
Problem is he saw that the tool was offering to 'fix' things that perhaps weren't quite right and saw a credible proposal to implement fixes, but the fixes were for bugs no one cared about or noticed and weren't security related, but incurred side effects that people did notice.
If you have a non-security bug that's been in place since 2019 and the only thing that noticed was an LLM analysis of your codebase, it may be best to let sleeping dogs lie...
load more comments
(2 replies)
For those who don't know, "tridge" is legendary.
He casually reverse engineered Microsoft's SMB protocol, creating Samba, back when windows file sharing was a key part of Microsoft's lock in. He also isn't just the maintainer of rsync, he invented the algorithms it uses. People who worked with him consider him a genius and a guru.
How much you want to bet he's just bombarded by the "ai security reports arms race" I saw on here a couple days ago, where people use LLMs to find security holes in open source projects (likely a form of 'fuck the dev' training)? I mean, for hundreds of reports to come in, some of which I'm sure are legitimate, is overwhelming to a team... and he's just one dude.
Edit. Looks like I may have been right. User Chairman Meow posted an excerpt from Discord that basically says that. Even legends get lonely, it seems.
Yep. A solo dev working on a project. Legitimate security flaws found by people who don't know much of anything about coding, but can prompt an LLM. They don't even understand the bugs they're submitting, so if he has questions they can't help.
His choice is either to spend all of his free time trying to patch these bugs, or to look for help. It's very hard to find help as a solo dev on an unsexy but essential tool. So, he turned to LLMs to help. And, who knows, maybe he's able to use them slightly more responsibly than other devs. But, LLMs almost inevitably lead to their own bugs because LLMs are always confident, and are designed to produce something that looks as much as possible like real working code, but without any actual thought or analysis behind them.
Which makes it all the more disturbing that he has turned to slopmachines.
If you read the discord chat logs, it makes sense. He's being bombarded by security vulnerabilities discovered via LLMs, from people who barely know how to code and can't even explain the flaw that their LLM discovered. He's a solo maintainer, and his choice is either to leave these security vulnerabilities open, or to turn to LLMs to try to keep up with the need for patches.
I don't think he made the right choice, but I think he's probably a much better programmer than me.
load more comments
(3 replies)
Honestly what happened to language models is a shame. Good tools perverted to try and do every job. LLMs dont really have a place and eat up so much resources with what effects to a okay scaffolding tool in code, and a piece of shit liar everywhere else. I remember seeing this shit being used in medicine almost 15 years ago thinking thats gonna be a cool technology to we expand. It was fucken not.
Neural networking has so much potential in so many places, yet of course the industry collectively zoomed in on LLMs specifically and is trying to sell them as a panacea to the world's problems.
As though a mechanical parrot knows anything about good coding practices, or literally anything outside of mimicking speech patterns.
load more comments
(5 replies)
load more comments
(3 replies)
Almost all of the latest commits on the project now :/
https://github.com/RsyncProject/rsync/commits/master/
+14k SLoC, -6k SLoC, most of it in May. In software that's mostly "done" and needs nothing else but bug fixes.
LGTM.
load more comments
(1 replies)
The slop continue until shareholders value improve
The project's issue tracker has been pretty wild recently, for example https://github.com/RsyncProject/rsync/issues/929
load more comments
(7 replies)
https://packages.debian.org/stable/rsync
Package: rsync (3.4.1+ds1-5+deb13u3)
slow and steady beybeee
I'm starting to think that I don't want to use Arch anymore and thus always be among the first to get all the new slop.
load more comments
(2 replies)
It's good to see AI sloppers already being confronted, dropped, and outcompeted.
load more comments
(4 replies)
You may not like it, but this is what 10x productivity looks like.
Move fast and break things. Features over stability.
Makes sense for a lean startup. Not so much for a widely used utility for backing up important data.
I'm a new and non-power-user of rsync. It seems like a pretty straightforward utility. What active development is even needed?
All software need active development. Dependencies change, new features are requested, bugs appear, ... Even the most simple utilities are concerned
That sounds mostly like maintenance, not active development, except for the feature requests.
This graph feels relevant:
load more comments
(2 replies)
load more comments
(2 replies)
Just gonna copy what tridge said:
bottom line is if you want to be useful then pick holes in the test suite, find things it doesn't cover, find interactions between options it doesn't pin down, report those and offer fixes for that.
Why ask for forks or alternatives?
load more comments
(5 replies)
rsync sucks now it really sucks
This is a duplicate thread but sure, imma just copy paste from my previous comment.
Here's the Discord dump for those who don't want to join (Tor not allowed, sorry I don't have a better file host, AI brought down 0x0.st). No further commentary.
[30.05.2026 10:05] andrewtridgell
I reviewed it. The rsync project has been essentially a single developer project for about 20 years now
[30.05.2026 10:06] andrewtridgell
Wayne did it all himself for a long time, now I'm back doing it
[30.05.2026 10:06] realketas
why is it one man job, it seems like too complex for that
[30.05.2026 10:06] realketas
i can't even imagine
[30.05.2026 10:06] andrewtridgell
nobody else volunteers. Its the same story with thousands of open source tools
[30.05.2026 10:07] realketas
it runs entire planet, just one man does it eh
[30.05.2026 10:07] realketas
sad too
[30.05.2026 10:07] andrewtridgell
the linux kernel has thousands of paid full time devs. rsync has zero.
[30.05.2026 10:15] andrewtridgell
the most insane part is that security releases can't be community tested. Those security releases are going to be a huge part of lots and lots of open source projects for a while to come yet, just look at the rate of CVEs over the last couple of months, its gone nuts. You can't do a beta release of a security fix as its embargoed. So for the most critical fixes you *can't* have anyone else look at it. The people reporting the flaws mostly don't have the skills as they used AI to find the bugs. So the maintainer is the sole person to review the most critical security changes, and that is how the madhouse called the internet and IT security is designed. The only defence I have is to build the most comprehensive and accurate test suite I can, so when I need to deal with yet another security report I can at least quickly identify what else the fix breaks. Luckily I can do that work (the dev of the test suite) in public.
[30.05.2026 10:22] andrewtridgell
bottom line is if you want to be useful then pick holes in the test suite, find things it doesn't cover, find interactions between options it doesn't pin down, report those and offer fixes for that.
Basically, it's a solo dev being swamped by LLM security reports, and since those are embargoed only maintainers can review them... and since nobody else has volunteered, he has to do it himself.
He primarily used several AIs to rewrite the test suite from shell (slow, lacking coverage) to python (parallelised, improved coverage). He says he's extensively reviewed everything, but I guess the suite doesn't cover everything. And the test suite changes can be community reviewed.
The dev has been actively inviting people to join as a maintainer and poke holes in the test suite, but it seems nobody has stepped up. I can't really blame the dev here, he just seems unable to keep up without others helping him out. He's tried to use AIs as sensibly as he could, and I'm not entirely sure if it's slop fixes that cause the issues (or if an "unassisted" fix would have caught it).
load more comments
(6 replies)
load more comments
(12 replies)
view more: next ›