If a person is going to be blamed, it should be the one that mandated use of the AI systems… Because that’s exactly what Amazon was doing.
Talk about an extra slap in the fuckin face… getting blamed for something your replacement did. Cool.
That’s in the SOP for management.
True. In this case, these poor saps being tricked into “training” these AI to eventually render their jobs obsolete.
Yes. “obsolete” in that Amazon doesn’t give a shit about reliability anymore, so an AI reliability engineer is fine, now. Haha.
Would said employees have voluntarily used the agent if Amazon didn’t demand it? If no, this isn’t on them. They shouldn’t be responsible for forced use of unvetted tools.
It blows my mind that people are going forward with this AI nonsense and that it has infected key infrastructure. I feel like im taking crazy pills here. I could kind of understand if it actually worked. Like if it genuinely worked as well as they said? I could totally understand it. I would still question it, but it would make more sense.
described the outages as “small but entirely foreseeable.”
LMAO
AI is working great!
It’s working great to convince moronic executives to leave Windows when it fucks up majorly due to AI coding, which is a win for everyone.
I mean, I’ll applaud any push toward Linux.
Yay! Extra mental load of having to ask the AI “correctly” and then keep up one’s skills to be able to review the AI’s work! Extra bonus for being blamed for letting anything slip past.
At least the junior that fucked up will learn something from the experience and can buy a round of beers (if the junior is paid well enough, otherwise the seniors have to buy the junior a beer while talking it out).
I’m reminded of a time I was in a bar in Georgia at a conference. It was in the hotel, and a high-ranking editor for the then-reputable Washington Post bought me a beer. He let me take a sip before launching into how much “immature shit [I] need to get out of [my] system” before being ready to be “Post material.”
Where is any industry going to be in a decade, when no one’s been mentored?
A computer (AI) can never be held accountable. Therefore, a computer (AI) must never make any human decision.
Well, AI code should be reviewed prior merge into master, same as any code merged into master.
We have git for a reason.
So I would definitely say this was a human fault, either reviewer’s or the human’s who decided that no (or AI driven) review process is needed.
If I would manage devOps, I would demand that AI code has to be signed off by a human on commit taking responsibility with the intention that they review changes made by AI prior pushing
If I would manage devOps, I would demand that AI code has to be signed off by a human on commit taking responsibility with the intention that they review changes made by AI prior pushing
And you would get burned. Today’s AI does one thing really really well - create output that looks correct to humans.
You are correct that mandatory review is our best hope.
Unfortunately, the studies are showing we’re fucked anyway.
Because whether the AI output is right or wrong, it is highly likely to at least look correct, because creating correct looking output is where (what we call “AI”, today) AI shines.
Realistically what happens is the code review is done under time pressure and not very thoroughly.
This is what happens to us. People put out a high volume of AI-generated PRs, nobody has time to review them, and the code becomes an amalgamation of mixed paradigms, dependency spaghetti, and partially tested (and horribly tested) code.
Also, the people putting out the AI-generated PRs are the same people rubber stamping the other PRs, which means PRs merge quickly, but nobody actually does a review.
The code is a mess.
@TehPers @Limerance why hadn’t you time to review it? Every minute in review pays off because it saves you from hours of debugging and handling with angry customers.
Sure, that’s the theory. In practice code review often looks like this:
- a quick glance to see if the code plausibly does what it claims for longer patches
- A long argument about some stylistic choice for short patches
In other words – people were barely reading merge requests before. Code reviews have limited effects as well. You won’t catch all bugs or see if it actually works just by looking at the code. Code reviews mainly serve to spread knowledge about the code among the team. The more code exists in a project, the harder it is to understand. You don’t want huge areas of code, that only one person has ever seen.
Project managers don’t necessarily talk to angry customers directly. They might also choose to chase more features instead of allocating resources to fixing bugs. It depends on what the bosses prioritize. If they want AI and lots of new features, that‘s what they will get. Fixing bugs, improved stability, better performance, etc. are rarely the priority.
@Limerance Well, on Friday I spent around 1.5 hours just reviewing a single PR. And I’m not done. I will have to continue my work on it on Monday. Reviewing in our company means understanding the connected use case, then having a look if the coding does what the use case defined. Also we look if the coding is done according to our internal style guide. Since our review is normally done by at least two people, (at most of our apps two people have to accept the PR until it can be merged) one person will see what the other missed. And we often talk about what the other missed, so that we learn.
Concerning angry customers: Our apps are used by several ten thousand users. And although our group doesn’t have direct customer contact, we get the bug reports and have to fix them anyway or we have to support the teams who directly work with the customers.
And I just realize that I’m in a very lucky situation. In our company each use case is tested thoroughly by the responsible QA and PO. And for each use case we write half a dozen (or more) test functions that check the functionality. Normally coding the tests takes more time then coding the use case itself.
Our company is very AI driven, but on the same hand we hear in the regular town halls about the customer satisfaction. And the goal there is to increase it steadily. Our customers are companies, so maybe there’s the difference.
AI can never fail, it can only be failed
