this post was submitted on 11 Jun 2026
101 points (99.0% liked)

Fuck AI

8223 readers
2397 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
top 50 comments
sorted by: hot top controversial new old
[–] Arghblarg@lemmy.ca 31 points 3 months ago (3 children)

I've recently had to begin dealing with this type of crap at my job in the past month, and it's infuriating.

Testers using LLMs to analyze logs, said LLMs cockily composing a multi-page 'bug report' stating the supposed cause, spewing a metric tonne of mostly irrelevant context and gaslighting with authoritative-sounding conclusions about the root cause of the issue; and since it sounds so damned confident in its verbose hallucinations, I have to waste precious time explaining to the test team and my manager why the report is mostly or entirely wrong.

Goddamn, I am so ready to retire. Let these "dark factory" advocates bury themselves in their models' slop. There will be a reckoning someday for this I swear; and if, someday, a company comes to me to clean up the mess "AI" has wrought, I will demand 3-4x my regular salary to clean it up, or, if I am financially content in retirement, I will simply tell them to go fuck themselves and lay in the bed they have made.

[–] victorz@lemmy.world 6 points 3 months ago

tell them to go fuck themselves and lay in the bed they have made.

Wouldn't that be oh so satisfying. 🀀

[–] criss_cross@lemmy.world 4 points 3 months ago* (last edited 3 months ago) (1 children)

My company loves having people shooting out vast amounts of PRs to other teams with surface level fixes to things we’ve been working on for months. You can tell none of them have been tested and only like 50% of them work. It’s infuriating.

[–] jj4211@lemmy.world 3 points 3 months ago

Oh yeah, that reminds me of yesterday. There was a problem and I was asked to look together with a guy from another team. The other guy was spinning out and spouting all sorts of wild ass guesses about the behavior and talking and talking about why it might be happening and why it calls for a change that would have been massively a pain in the ass for the user, but in principle would solve the issue if implemented, and pressuring me to make those changes right that second.

I said just wait a moment, gave a patch that just simply fixed the problem, explained the actual root cause, why it was a very quick fix, and used the balance of the time to improve performance because the experience was slower than I liked, even if the customer had not complained about it (something took about 2 minutes that should have been near instant, but they just "assumed that's the way it is").

No AI involved whatsoever, but a very AI like behavior of spouting nonsense that sounds right and just shotgunning off some design in hopes of it doing something, no matter how messy.

Just an example of why AI is so "exciting" in the tech industry, so many are already used to just guessing without understanding and hoping it works.

[–] jj4211@lemmy.world 1 points 3 months ago

I'm with you, but so so far away from retiring.

Silver lining is that the company refuses to pay for more than included GitHub copilot tokens. They are currently in denial and saying folks can just use the cheap models to build management's dream of "native agentic workflows", but I fully expect them to have to face the reality that people will get fancy tab completion and the occasional prompt and that's it. I can deal with that volume.

But still after each model release I go to use it and save examples of it falling on its face. Because each time a new model launches management is convinced that the llms don't make mistakes anymore. If they just said it is getting better that would be one thing, but they are always convinced that new LLM was when all the issues were fixed.

Working on open source has been tougher, since other people have blown budget on making harder to understand bug reports and pull requests.

[–] victorz@lemmy.world 29 points 3 months ago* (last edited 3 months ago) (4 children)

Actual comment proving it's bullshit: https://github.com/rhinstaller/anaconda/pull/7074#issuecomment-4556782893

But the PR is still merged. What does that mean. They just accepted it anyway? 😒

Edit: it was reverted, I hear ya πŸ™πŸ€Ÿ

[–] Azzu@leminal.space 21 points 3 months ago* (last edited 3 months ago) (1 children)

That's what happens when you don't actually understand the change and just listen to whoever is posting it. The disingenuous thing about LLMs is that they present their hallucinations with full confidence in a charismatic way. No matter the source, that is how anyone can mislead other humans, we're just so extremely susceptible to it.

[–] victorz@lemmy.world 3 points 3 months ago

we're just so extremely susceptible to it.

Judging by the leaders of the world throughout history β€” yes we are indeed. And it's so sad.

[–] unrulyhillperson@piefed.social 13 points 3 months ago* (last edited 3 months ago) (1 children)

Looks like it was reverted shortly after the comment you posted.

[–] one_old_coder@piefed.social 13 points 3 months ago (2 children)

I didn't notice that. The fact that Redhat is merging random crap is scary.

[–] katze@lemmy.4d2.org 3 points 3 months ago (11 children)

Not really, it matches the Redhat software quality that we had a joy to experience for the last 10+ years (systemd, pulseaudio, Gnome, ...)

[–] BOplaid@discuss.tchncs.de 2 points 3 months ago

GNOME is getting bad but in my experience systemd is just drama (and fine) and pulseaudio is still just fine

load more comments (10 replies)
[–] jj4211@lemmy.world 2 points 3 months ago

Well, this case the actual little 'code change' is pointless, but harmless, so not so scary. The rationale is stupid because the purported root cause makes no sense against the behavior, but preserving a custom boot parameter added to install to also apply to the installed OS is pretty milquetoast.

[–] jj4211@lemmy.world 3 points 3 months ago (1 children)

Yeah, I was reading the comment before and anyone with a vague awareness of this stuff should have called bullshit immediately.

Preserving the argument seemed an innocuous enough change though, so I could see why it was accepted, but the explanation was bafflingly stupid.

But people who don't know eat it up. Sounded possible (until they claimed the system crashed and could not log the error, despite a log entry belt there that they ostensibly cite as the issue..).

[–] victorz@lemmy.world 4 points 3 months ago (5 children)

I just don't understand the workflow with these people.

You know how people say "don't run a command you are given or find online unless you know exactly what it does"?

Why would anyone accept/merge a PR from an LLM unless they knew what the consequences were, or verified its claims. I just will never get this trust in LLMs, given I know even vaguely how they work.

[–] jj4211@lemmy.world 1 points 3 months ago (2 children)

Well, in this case, the actual change is pointless, but also relatively harmless. If the user puts "split_lock_detect=" during install, then it just carries it forward into the installed environment.

It's frankly a bit weird that they assume a kernel argument during install would not carry over, except in select circumstances. I get it for parameters like "here's a kickstart file" or "here's the net configuration to boot with", which would be filtered out via a blacklist, but they have a whitelist and assume most parameters should be ignored.

But anyway, I can see someone looking at the code change, not recognizing why someone would want that argument, but shrug and say "sure, simple enough, it won't impact the vast majority of people and those that bother for whatever reason will just see it carried forward".

load more comments (2 replies)
load more comments (4 replies)
load more comments (1 replies)
[–] northernlights@lemmy.today 17 points 3 months ago

Wow what a massive waste of everybody's time.

[–] pixxelkick@lemmy.world 4 points 3 months ago (4 children)

Yeah, LLMs are gonna spin their wheels hard when it comes to testing anything at the kernel/os level, if you dont have automated testing with a virtual machine setup to actually be able to replicate a bug, you 100% just cannot test anything they produce or say

As soon as you have the ability to go "Okay we have a failing test, make it pass", the LLMs get a lot less stupid, because instead of just randomly fumbling around and guessing, they have actual feedback to iterate on and can actually chew on it til they fix the issue or give up.

[–] schipelblorp@sh.itjust.works 2 points 3 months ago (1 children)

I'm not a programmer, but isn't reproducing a reported bug step 1?

[–] pixxelkick@lemmy.world 4 points 3 months ago

Reproducing the bug with an automated test is harder, its code you can run that tests your other code.

But allows you to just 1 click run it and get a yes/no "is this still broken" output without having to manually reproduce it by hand each time.

Whats important is this is in the domain of what LLMs can actually work with, the output of the test is something they can parse and iterate on until it works.

They execute the command to run the test, check the output, and keep working til the test passes.

They can add additional tests to help isolate the problem, or strip down the existing test until its doing the absolute bare min steps to reproduce, in order to narrow the scope of whats causing it.

But when your test involves stuff running in the kernel of an OS, your automated tests meed to effectively be code you write that bootstraps a virtual machine up and manipulates and observes that second machines kernel...

You can do it, but its one of the most complicated forms of automated tests to design and run!

load more comments (3 replies)
load more comments
view more: next β€Ί