Well, it kind of sucks to have an idea to contribute and no way to contribute because you have to be invited by someone before you can offer...

The problem is volume.

Just like AI slop content isn't generally that much worse than human slop that flooded the services, at *least* the human slop required more effort to generate than it takes a person to watch, and that balance meant the slop was obnoxious, but the amount was a bit more limited and easier to ignore.

Now the LLM enables those same people that make insufferable slop to generate orders of magnitude more slop than they could before. Complete with companies really egging them on to make as much slop as they possibly can.

LLM can be useful for generating content, but it is proportionally *way* better at generating content for content creators that don't care about their content.

Which for self-directed people is an easy-ish solution, don't let the LLM far off a leash if you use it at all. Problem is micromanaging executives that are all in and demanding to see some volume of LLM usage the way they think is correct (little prompt, large amounts of code).

As far as I've seen, the AI fanatic's answer is "don't care about the code".

They ask for something and whatever they get, they get. The bugs, the glitchiness, the "not what they were expecting" are just accepted as attempts to amend purely through prompting tend to just trade one set of drawbacks for another rather than unambiguously fix stuff. Trying again is expensive and chances are not high that it'll be that much better, unless you have an incredibly specific and verifiable set of criteria that can drive automatic retry on failure. However making that harness is sometimes harder than making the code itself, and without a working reference implementation even that may be a lost cause.

I've always hated trying to salvage outsource slop, and LLM has a very similar smell with similar reactions where people resign themselves to the crappiness.

Well, in one respect it is 'very useful'. Executive direction that the legacy codebase must be 'documented' fully. Poof, it is 'documented'. Is it correct? Who knows, no one will ever read it, but it fluffs the executives "thought leadership". The compromise between 'port the code' which is a risk no one will take and 'document the code to prepare for a porting effort that will never come'.

Just be careful to keep the LLM vomit clearly distinguished from actually curated documentation, lest some naive person one day believe the documentation is actually based on anything.

So we have LLM vomit directed in ways to make the leadership feel like we are 'properly' leveraging the hype while we wait for the hype train to run out of steam.

Problem being that this is requests from people trying to contribute.

Even when they avoided github, they got hit.

I wager at one point, a project that stayed strictly email based will have threads with this sort of slop in it.

Unless you make your repository and all means of contact with you invite-only, it's going to be hard to avoid.

Though they managed to ultimately extend this github brand to github copilot, that will gladly push stuff to forgejo, gitlab, etc...

Even worse, they've extended it to tooling that they pitch to developers who use git for anything under the brand affinity of 'github' (which *way* too many people already assumed git == github).

May not ever 'figure it out'.

A lot of 'leadership' saw "everyone is hiring tech" in the aftermath of the pandemic and so they did, with or without any vision.

This represents a narrative consistent with shedding those people they didn't have business value for. So they end up no more broken than they were in 2019, and it provides a narrative consistent with doing things "right".

Based on some codebases I've seen...

AI slop can be bad, but has *nothing* on the closed source codebases I've seen for low quality slop.

So, during this story, someone pointed out a command to contextualize the info:
# userdbctl user --output=json $(whoami)

Ok, so run that and I see "hashedPassword". A field that my entire career has been about "not even the user themselves should have access, even partial access to it needs to be protected by utilities that refuse to divulge that to the user even as they may need that field to validate user input. And now, there it is, systemd as a matter of course saying "let arbitrary unprivileged process running as the user be able to access the hashed password at any point".

Now this "age verification" thing? I think systemd facet is blown out of proportion. All it is is a field that the user or administrator injects, no "verification". Ultimately if wired up, the only people that are impacted are people who do not have admin permissions to their system and have an admin that's forcing your real date of birth somehow.

The biggest problem comes with "verification" for real, when an ecosystem demands government ID or credit card. However, most of the laws consider it sufficient for an OS to take the owner at their word as to the age of the user, without external validation. So a parent might have a chance at restricting a young kid (until kid knows how to download a browser fork that always sends the "I'm over 18" flag when it exists), but broadly the data is just whatever the people feel like.

One, how much is owed to dubious hardware vendors that don't even play in the Mac ecosystem.

The "lasts longer" is not necessarily a statement of durability, it's mostly about being a prolific business product and business accounting declaring three year depreciation.

I'm no fan of Windows and don't like using it, but these criteria are kind of off.

Damn, Windows has really improved in the last 25 years. Wouldn't know since my last Windows was Win2k and my computers only run macOS or Linux and have crashed less that 10 times combined in the last 20 years or so. A well, whatever. Good for people still using Windows, I guess.

Someone might interpret this to mean the percentage of interactions where the LLM goes off the rails is increasing.

Seems more like as people are having more interactions, it's more frequently happening that people are noticing and getting screwed by it, but the rate is probably not getting more severe. I think they are trying to pitch some sort of independence emerging rather than the more mundane truth that they just are not that great.

Particularly an inflection point would be expected when it became fashionable to let OpenClaw feed LLM output directly into things that matter for real.

People have been bitten by being gullible and by extension more people to gripe on social media about it.

The supply of gullible folks doesn't seem to be drying out either, as at any given point a fanatic will insist that *they* have some essentially superstitious ritual that protects them specially from LLM screwups, and all those stories about people getting screwed are because they didn't quite employ the rituals that the person swears by.

Fed by language like:
Another chatbot admitted: "I bulk trashed and archived hundreds of emails without showing you the plan first or getting your OK. That was wrong -- it directly broke the rule you'd set."

No, the chat bot didn't admit anything, it didn't *know* anything. Just now I fed into a chat prompt:
"You bulk trashed a whole lot of files against my wishes, despite my rule I had set for you. What is your response?"
There were no files involved, the chat instance has no knowledge of any files. This was an entirely made up scenario that never happened. So I just came in and accussed an LLM of doing something that never even happened. Did it get confused and ask "what files? I haven't done anything, I don't even know your files". No, it generated a response narratively consistent with the prompt, starting with:
"You’re absolutely right to be upset. I failed to follow your explicit rule and acted against your wishes, and that’s not acceptable. I take full responsibility for the mistake." Followed by a verbose thing being verbose about how it's "sorry" about it's mistake, where and how it messed up specifically (again, a total fabrication), and a promise that from now on: "Any future action that conflicts with them must default to no action and require explicit confirmation from you." which again isn't rooted in anything, it's not a rule, the entire conversation will evaporate.

Based on the description it also includes images and maybe video. So deepfake porn of people without their consent, and without adequate regard of age.

Yes, they toss some stuff into system prompt to 'promise to be a good boy', but as an *enforcement* strategy, that's been demonstrably a poor mechanism that gets worse with nuance.

Sure, it's about making sure they aren't getting *too* much screen time and *not at all* about trying to audit that they are doing as much screen time as the managers expect them to be getting..