[petterroea]

My understanding is that AnonC is upset at Ars not taking the mature approach by allowing this to become a learning moment for the employee and using it to double down and confirm their stance on AI generated content. There's strength in maturity. But I am doing some reading between the lines, and I'm possibly reading a bit too much into "There’s something to be said about the value of owning up to issues"

Reminds me of a story I was told as an intern deploying infra changes to prod for the first time. Some guy had accidentally caused hours of downtime, and was expecting to be fired, only for his boss to say "Those hours of downtime is the price we pay to train our staff (you) to be careful. If we fire you, we throw the investment out the window"

[lynx97]

There is a difference between an error and totally misunderstand your actual task. I have absolutely no sympathy for journalists getting caught producing hallucinated articles. Thats an absolute no go, and should always result in that person being fired.

[jcgrillo]

Same goes for engineers reviewing vibeslop. If you let that shit through code review, and a customer impacting outage results, that should be instant termination. But it won't be, because as an engineer you are supposed to be held "blameless" right?

[pixl97]

Hence why software engineers aren't an actual professional licensed engineers.

[mikkupikku]

I love vibe coding but you are absolutely right. We're at the stage where vibe coding is a fun way to produce sloppy software and that's fine if the intended user is just yourself and you're fully informed about what you're getting into. But actually shipping vibe coded slop to other people is wacky, anybody doing the needs to be manually reviewing every commit very carefully and needs to be prepared to accept personal responsibility for anything that slips by.

[jcgrillo]

The problem is that reviewing code for correctness is harder than writing correct code. So these things will always slip through review. I'm a little bit divided here whether we can (or should) blame a reviewer too harshly for letting broken code through review whether it's LLM or human generated.

I've worked on teams with a rubber stamp review culture where you're seen as a problem if you "slow things down" too much with thorough review. I've also worked on teams that see value in correctness and rigor. I've never worked on a team where a reviewer is putting their job on the line every time they click "Approve". And culturally, I'm not sure I'd want to.

That said I think it's pretty clear we need mechanisms that better hold engineers to account for signing off on things they shouldn't have. In some engineering domains you can lose your license for this kind of thing, and I feel like we need some analogous structure for the profession of software engineering.

[watwut]

Joirnalist job was not to review ai-slop. That is rather crucial difference.

[watwut]

Accidentally taking down production should not lead to firing. It should lead to improved process

Making up quotes for article, with technology or not, should lead to firing.

[oneeyedpigeon]

"should lead to firing..."

... and, also, improved processes. There should be no way an individual writer can damage the brand to this extent with absolutely no checks or oversight. This was just an error, but a bad actor could've put something far, far worse out there.

Even an automated quote-checker might have helped in this case.

[jcgrillo]

Fact checking is a vital part of the editorial process and clearly that process failed here. Tech people often have a double standard when it comes to journalism--rules for thee but not for me. However the structure is fairly analogous, in that both professions ship under lots of time pressure where mistakes can be costly. I'm not sure, honestly, who is most at fault here or why only the reporter was terminated. But my comment above was to highlight that there shouldn't be a double standard--if you think a journalist should be fired for this kind of error it would be inconsistent to believe a software engineer shouldn't.

[bandrami]

"Make sure quotes in your article are things the subject actually said to you" is not something that should need a "learning moment".