Log in
Amazon Web Services is the biggest cloud provider. Large chunks of the internet run on AWS. You’ll pay and pay. But it basically works.
Amazon’s at work on fixing that. The AI push across Amazon has reached AWS.
The site reliability engineers who keep Amazon Web Services running are being forced to use AI bot coding when the details are important — and expensive. When the bot goes wrong, the employees get the blame!
The Financial Times dug out the story. A service went down for 13 hours in December specifically because of Amazon’s whizz-bang new in-house vibe coding tool, Kiro: [FT, archive]
the agentic tool, which can take autonomous actions on behalf of users, determined that the best course of action was to “delete and recreate the environment”.
Amazon released a post-mortem internally, which the FT got wind of.
FT spoke to multiple people at Amazon who said this was the second vibe-outage in recent months.
The previous outage used Amazon’s old Q vibe coder, not the new Kiro vibe coder.
Kiro must have been named by someone in Finland — in Finnish, “kiro” is a word root for “curse” or “swear,” as in profanity.
Amazon tried hard to play it down:
Amazon said it was a “coincidence that AI tools were involved” and that “the same issue could occur with any developer tool or manual action”.
The company said the incident in December was an “extremely limited event.”
That only means they didn’t have a bigger outage yet. Amazon’s hard at work on it, though:
Some Amazon employees said they were still sceptical of AI tools’ utility for the bulk of their work given the risk of error. They added that the company had set a target for 80 per cent of developers to use AI for coding tasks at least once a week and was closely tracking adoption.
As one senior AWS person told FT:
the outages were small but entirely foreseeable.
Amazon is absolutely clear who’s to blame for all this — this 13-hour outage caused by their own bot turning something off and on again is officially user error!
Amazon said that by default its Kiro tool “requests authorisation before taking any action” but said the engineer involved in the December incident had “broader permissions than expected — a user access control issue, not an AI autonomy issue”.
That sounds like the tool was forced into place and nobody thought very hard, because they were always going to blame the human.
One person in the FT comments calls out how this actually works in practice:
I’ve seen the internal usage and actions of Kiro … and it also deleted my own environment. The fallacy of blaming this on “broader” permissions is a crazy delusion. The tool can also detect it doesn’t have enough privileges and it will assume them … you need to “trust” or it will force you to become a bot pressing “continue” constantly, defeating the argument of automation.
But you’ll be delighted to hear Amazon is trying to vibe-fix those annoying humans:
“Following the December incident, AWS implemented numerous safeguards”, including mandatory peer review and staff training.
