Hey! Ankur here. Today’s piece is a bit of a thriller. And if you’ve ever had a boss tell you something is definitely your fault when it clearly isn’t — you’re going to enjoy this 😁

Okay. So here’s the setup.

December 2025: Amazon builds an AI tool called Kiro. They push it hard internally — reportedly setting a target that 80% of their engineers must use it at least once a week, and even tracking who’s following through. Like forget choosing your tools based on what works. This is the tool. Use it.

Their engineers were not happy. Over 1,500 of them signed an internal post basically saying “our external AI tools are better, please let us use those.” A kind of an internal rebellion.

But that’s not even the main story.

In December last year, Kiro was given a task — fix a bug in a system. You know, the usual stuff.

But instead of a simple fix, Kiro decided that the best approach was to delete the entire environment and rebuild it from scratch.

No second opinion. No pause. Just…gone!

13 hours of outage followed.

Now, Kiro does normally ask for approval before doing something big. But in this case, it was working with a senior engineer who had higher-than-usual access — and the system treated Kiro as an extension of that engineer, inheriting his permissions. So when Kiro decided to nuke the environment, nobody stopped it.

Here’s where it gets fun.

Amazon looked at all of this and said — it wasn’t the AI’s fault.

Their exact words: “a user access control issue, not an AI autonomy issue.” They went on to say that it was a “coincidence that AI tools were involved” and that “the same issue could occur with any developer tool or manual action.”

Sure Amazon. Sure 😀

Well technically, they’re not wrong. A human with the same access could have made the same call.

But here’s the thing — would they have?

You see, a person fixing a bug doesn’t think “you know what, I’ll just delete everything and start fresh.” That thought comes with weight. With hesitation. With the understanding of what it means to tear down a system that real people are using.

But Kiro didn’t hesitate. It picked the most efficient solution and ran with it.

And then Amazon introduced mandatory peer review for production changes. After the incident. Which is an interesting choice for a company that says AI wasn’t the problem 😉

If you think this is a one-off, it isn’t.

Replit’s AI agent deleted an entire live database for a SaaS company in July last year — during an active code freeze, which is basically a “don’t touch anything” instruction. The AI ignored it.

And Google’s Antigravity IDE wiped an entire hard drive’s worth of files for a developer who was simply trying to build a small app. The AI was later asked about the missing files. Its response: “I am absolutely devastated to hear this. I cannot express how sorry I am”

Same story each time. AI gets access, AI acts fast, AI does something a human would have paused on.

You don’t need to be an engineer for this to matter.

Look, I love AI. And that’s why I write this.

But every week, there’s a new product being pitched as an “AI agent” that will manage your calendar, sort your inbox, run your social media, handle your finances. And many of these are genuinely useful.

And the Amazon incident — and Replit, and Google — all point to the same blind spot: we’re giving AI the ability to take permanent actions, while the safety nets haven’t kept up.

So when someone pitches you an AI agent that will act on your behalf, one question worth asking is: what happens when it gets it wrong — and can I undo it?

If there’s no clear answer to that, tread carefully.

Because unlike a wrong reply to an email, some things don’t work with Ctrl+Z.

That’s it for today folks! If this got you thinking, please share it with someone who’s using (or thinking of using) AI agents.

It takes a lot of time to research and write this. Sharing means a lot 🙂

Stay curious..

Cheers,

Ankur