When I get a report which is obviously LLM output, I do not read it.

[icing@chaos.social]

@dbof It depends on the situation. If your boss drop LLM output into your inbox and think that is the way to go, you are probably very limited.

If a random person drop such a thing into your project, you can refuse to process it without further work by the submitter.

I experience LLM output as part of being a maintainer. And a FOSS project should not feel obligated to accommodate such behavior, IMO.

I do not care what tools someone uses. I care how we communicate and collaborate.

[akamran@indieweb.social]

@icing I just told a student in an online only class to edit the wall of words or else. I'm an adjunct, I'm not paid enough to wade through shit.

[endlessmason@hachyderm.io]

@dbof @icing
How do we react when people make mistakes with other tools?

[dbof@infosec.exchange]

@EndlessMason @icing often we blame the users, sometimes the tools!

"Oh, you got hacked? You're to blame!"
"the spreadsheet calculated the wrong value"

In IT we always assume the computer does exactly the thing you tell it to do so it is never "wrong", you just put the wrong input out used or wrong. Yes, programs have bugs, but that is introduced by humans.

So should we blame humans for computer / algorithm / llm output? It's not so clear cut in my opinion.

[kgf@hachyderm.io]

@dbof @EndlessMason @icing Except in the case of LLMs it is nearly the opposite: the computer never does exactly the thing you "tell" it to do, so it is never "right", only plausible-looking. Using an LLM at all is _begging_ for bugs.

[endlessmason@hachyderm.io]

@dbof @icing
Hint: the Human selected a tool that made it either difficult or impossible for them to do a good job... and then they did a bad job.

Improving operator, tool, and environment can all contribute to better results...

I also think we're well past "computer does what operator says" especially on corp controlled autoupdate endpoints speaking to a sea of random corp clouds

[dbof@infosec.exchange]

@kgf @EndlessMason @icing yeah of course, so that is the change. But non-it people do not know these flaws. They don't know (or ignore) how LLMs work. They also don't know how Photoshop works.

How do we evaluate this then?

[staringatclouds@mstdn.social]

@icing

"Thank you for your LLM generated report, I have passed it on to an LLM to read, the portion of your salary which would have paid you to write this report will be passed to the LLM owners instead"

[endlessmason@hachyderm.io]

@dbof @kgf @icing
Any of: Kill chains, Root cause analysis, Swiss cheese model, defence in depth, site safety procedures/policy mechanisms, staff training, education / certification, regulation about how it can be advertised, restrictions on places where those tools can be used (no not work near flammable gasses), making it a security/safety/compliance issue, administrative approvals/restrictions, ACLs etc

There are already metaphorical matches to tasks in non-IT industries for how to treat things that act violently / non-intuitively / unpredictably - I'm sure those procedures are a decent place to start.

Generally, they all orbit around whittling down the chances of a mistake being made, and whittling down the chances that something goes wrong when a mistake is made.

[burly@olifant.social]

@dbof @icing Where I work llm code is your code and you are responsible for what it does. Blaming ai will not work.

[cafeinux@infosec.exchange]

@timsk
You were too kind. I'd have said that "I could have cancelled the fees because X and Y, but due to the fact that you made me read 8 pages of AI slop, please consider these fees as the tax to pay for my time."
@icing

[timsk@mastodon.social]

@cafeinux @icing ha, good idea. Next time!