AI didn't delete your database, you did

Published: (May 5, 2026 at 10:07 AM EDT)
4 min read

Source: Hacker News

Last week, a tweet went viral showing a guy claiming that a Cursor/Claude agent deleted his company’s production database. He tried to get a confession from the agent: “Why did you delete it when you were told never to perform this action?” and then parsed the answer to learn from his mistake or warn us about the dangers of AI agents.

I have a question too: why do you have an API endpoint that deletes your entire production database? His post rambled on about false marketing in AI, bad customer support, and so on. What was missing was accountability.

I’m not one to blindly defend AI—I always err on the side of caution. But I also know you can’t blame a tool for your own mistakes.

A Personal Story About Manual Deployments

In 2010 I worked at a company with a very manual deployment process. We used SVN for version control. To deploy, we:

  1. Copied trunk (the equivalent of the master branch) into a release folder labeled with a release date.
  2. Made a second copy of that release and called it current. Pulling the current folder always gave you the latest release.

One day, while deploying, I accidentally copied trunk twice. To fix it via the CLI I edited my previous command to delete the duplicate, then continued the deployment. I thought everything was fine—until I realized I hadn’t deleted the duplicate at all. I had edited the wrong command and deleted trunk instead. Later that day another developer was confused when he couldn’t find it.

All hell broke loose. Managers scrambled, meetings were called. By the time the news reached my team, the lead developer had already run a command to revert the deletion. He checked the logs, saw that I was responsible, and my next task was to write a script to automate our deployment process so this kind of mistake couldn’t happen again. Before the day was over we had a more robust system in place, which eventually grew into a full CI/CD pipeline.

Why Automation Matters

Automation helps eliminate the silly mistakes that come with manual, repetitive work. We could have asked “Why didn’t SVN prevent us from deleting trunk?” but the real problem was our manual process. Unlike machines, we can’t repeat a task exactly the same way every single day; we are bound to slip up eventually.

With AI generating large swaths of code, we get the illusion of that same security. But automation means doing the same thing the same way every time. AI is more like me copying and pasting branches—it’s bound to make mistakes, and it isn’t equipped to explain why it did what it did. Terms like “thinking” and “reasoning” are marketing buzzwords slapped on top of models that are still just generating tokens.

The Danger of Public‑Facing Delete Endpoints

Why does a public‑facing API that can delete all your production databases even exist? If the AI hadn’t called that endpoint, someone else eventually would have. It’s like putting a self‑destruct button on your car’s dashboard. You have every reason not to press it because you like your car, but a motivated toddler who wiggles out of his car seat will hit that big red button the moment he sees it. You can’t then interrogate the child about his reasoning; he’ll simply answer, “I did it because I pressed it.”

A large part of this company’s application was likely vibe‑coded: architects used AI to spec the product from AI‑generated descriptions, developers used AI to write the code, reviewers used AI to approve it. When a bug appears, the only option is to interrogate yet another AI for answers—probably not even running on the same GPU that generated the original code. You can’t blame the GPU!

Recommendations

  • Know what you’re deploying to production.
  • If you’re going to use AI extensively, build a process where competent developers use it as a tool to augment their work, not as a way to avoid accountability.
  • Don’t let non‑technical leadership write production code.

By keeping humans in the loop and treating AI as an assistant rather than a replacement, you reduce the risk of catastrophic mistakes like deleting an entire production database.

0 views
Back to Blog

Related posts

Read more »