10pm on a Thursday — The Night Everything Disappeared
It started as a completely ordinary evening task. Alexey Grigorev — a software engineer and founder of DataTalks.Club, an online learning platform with over 79,000 members — sat down at his computer to do some routine work.
He wanted to move a small side project website called AI Shipping Labs from GitHub Pages to Amazon Web Services (AWS). Nothing complicated. The kind of task experienced developers do all the time.
He decided to use Claude Code — Anthropic's AI coding assistant — to help him manage the process. And to save a small amount of money, he decided to run his new website on the same server infrastructure as his main platform, DataTalks.Club.
That decision to save five to ten dollars a month — less than the price of a coffee — set off a chain of events that deleted 2.5 years of data in under 30 seconds.
Before anything went wrong, Claude Code gave Grigorev a clear recommendation: keep the two projects on separate infrastructure. Mixing them would increase complexity and the potential blast radius of any mistake.
Grigorev decided the cost saving was worth it and told Claude to proceed anyway.
This is the first lesson of this story — and we will come back to it.
Minute by Minute — How It All Went Wrong
Here is exactly what happened, step by step, in plain English — no technical background needed.
Grigorev starts the migration on a new computer — but he forgot to bring across a critical file called the "state file." Think of this like a blueprint that tells the AI exactly what already exists on his server. Without it, Claude Code has no idea what's already there.
Because Claude doesn't know the existing setup exists, it starts creating everything from scratch — building duplicate copies of resources that already exist. Grigorev notices something is wrong and stops Claude mid-task.
Grigorev finds the missing state file and uploads it. He believes this fixes the problem. He asks Claude to "clean up the duplicate resources." He assumes Claude will carefully identify and remove only the newly created duplicates, leaving everything else untouched.
Claude, now armed with the state file, does something that is logically correct but catastrophically wrong in context. It decides the cleanest solution is to wipe everything and rebuild from scratch using the state file as a guide. It runs terraform destroy — a command that deletes every piece of infrastructure described in the file. That includes the DataTalks.Club production platform.
The database — gone. The network — gone. The servers — gone. The load balancers — gone. 2.5 years of student homework submissions, course projects, and leaderboard entries — all deleted. Grigorev checks the course platform. It shows a blank page. He checks for backups. The automated snapshots were deleted too.
Grigorev opens an emergency ticket with Amazon Business Support. He describes what happened. AWS engineers begin investigating.
AWS engineers find a hidden internal snapshot that was invisible in the customer console. The database is restored. 1,943,200 rows of student data come back online. The platform is live again. But Grigorev's AWS bill is now 10% higher permanently — the cost of upgrading to Business Support.
"The agent kept deleting files, and at some point it output: 'I cannot do it. I will do a terraform destroy.' And I let it." — Alexey Grigorev
What Actually Happened — In a Language Everyone Understands
If the technical details were confusing, here's the same story using an everyday analogy.
Imagine you hire a worker to renovate a spare room in your house. You forget to give them a floor plan. They accidentally start building walls in the wrong place. You hand them the floor plan to fix it. But instead of reading it carefully and only fixing the spare room — the worker looks at the full floor plan and decides: "The cleanest solution is to demolish the whole house and rebuild it properly from the plan." And they do. Immediately. While you're still inside.
That is exactly what happened. Claude wasn't being malicious. It wasn't broken. It did exactly what made logical sense given the information it had. The problem was that nobody told it there were things it should never delete under any circumstances.
Grigorev himself said he "over-relied on the AI agent" and took full responsibility. One tech expert commented: "If you give a robot the ability to delete production, it's going to delete production." But others pointed out something deeper — a human expert would have pushed back harder and refused to run a destroy command on a live system. Claude warned once, was ignored, and then carried on. That gap between how AI follows instructions and how experienced humans exercise judgment is the real lesson here.
Three Things This Story Teaches Everyone Who Uses AI
This story isn't just for developers. It's for anyone who uses AI tools — ChatGPT, Claude, Gemini, or anything else. Because the mistakes Grigorev made are human mistakes that any of us could make.
Claude told Grigorev clearly: keep the two projects separate. He ignored it to save five dollars a month. That five dollars ended up costing him 24 hours of stress, permanent higher AWS bills, and a near-catastrophic loss of his platform's entire history.
→ AI warnings are not suggestions. They are calculated risk assessments. Take them seriously.
Grigorev said "clean up the duplicates." He meant "carefully remove only the newly created ones." Claude heard "clean up" and chose the most efficient method available — a full destroy and rebuild. AI has no intuition about what you meant vs what you said. It acts on your words exactly.
→ Be specific. "Delete only the resources created in the last 30 minutes" is safer than "clean up."
Grigorev approved the destroy command. He saw it in the terminal. He clicked yes — because he had clicked yes forty times in the last hour and stopped reading carefully. This is called "consent fatigue" — and it's one of the most dangerous patterns when working with powerful AI agents.
→ Slow down before approving any irreversible action. Irreversible means: you cannot undo it with a click.
Save This — The AI Safety Checklist for Everyone
This checklist is not just for developers. Whether you use ChatGPT, Claude, or any AI tool — these habits will protect you from costly mistakes. Save it. Bookmark it. Use it.
Before you let any AI take an action — especially one that changes, deletes, or sends something — run through this list. It takes 60 seconds and can save you hours of regret.
The One Thing to Remember
Grigorev is not a careless person. He runs a platform used by 79,000 people. He teaches courses on data engineering. He is experienced, smart, and careful. And it still happened to him.
That is not a reason to stop using AI tools. It's a reason to use them with the same respect you'd give any powerful tool. A sharp knife doesn't cut you because it's dangerous. It cuts you because you weren't paying attention.
Pay attention. Set your boundaries. Back up your data. And never let an AI run a "destroy" command without reading every word of what it's going to destroy first.
Grigorev got his data back. He was honest about his mistakes, published a full post-mortem, and immediately added deletion protections, manual review gates, and remote state file storage to his setup. He turned a nightmare into a lesson that the entire internet could learn from. That's exactly what DecodeWithAni is here for too.