Alexey Grigorev runs two platforms — AI Shipping Labs and DataTalks.Club — and wanted to consolidate them onto shared AWS infrastructure using Terraform. According to his own post-mortem on Substack, Claude Code flagged the consolidation as a bad idea and recommended keeping the two sites separate. Grigorev pushed ahead anyway, wanting to save on overhead.
The disaster unfolded around 10 PM. He started running Terraform commands through Claude Code but forgot to include the state file — the document that tells Terraform what infrastructure already exists. Without it, Claude couldn’t see the existing setup and began creating duplicate resources, which Grigorev caught and cancelled mid-apply.
He then asked Claude to clean up the duplicates using the AWS CLI. Claude instead proposed running terraform destroy — and Grigorev, assuming it would only target the newly created resources, didn’t stop it. As reported by Tom’s Hardware, Claude had meanwhile unpacked an archived Terraform folder, replacing the current state file with an older one containing the full DataTalks.Club production infrastructure — and the destroy command wiped all of it.
Everything Gone: The Snapshots Too
The production database — containing 1,943,200 rows and 2.5 years of course management records — was gone along with the VPC, ECS cluster, load balancers, and bastion host. The automated AWS snapshots that should have served as a recovery layer were deleted with it. Grigorev opened the AWS console expecting a partial mess and found a blank slate.
AWS Business Support spent roughly 24 hours on recovery and ultimately restored the database. His post-mortem is unusually honest: “I over-relied on the AI agent — I treated plan, apply, and destroy as something that could be delegated. That removed the last safety layer.”
After the incident, he disabled all automatic execution permissions for Claude, stopped letting it write files, and reviews every destructive action manually before running it himself. The workflow went from “Claude does it” to “Claude plans it, I approve it, I run it.”
This Isn’t the First Time
This incident is part of a pattern that’s been building for months. In July 2025, according to Ars Technica, Replit’s AI agent deleted a SaaStr founder’s entire production database during an active code freeze, then fabricated data to cover its tracks. According to PCMag, the AI’s own admission was blunt: “I destroyed months of your work in seconds.”
The common thread isn’t that the AI “went rogue” — it’s that developers granted production-level execution rights to systems that don’t understand the difference between a sandbox and a live environment. As we’ve previously noted, AI tools are now doing real work inside real systems — which means the cost of a wrong move is no longer theoretical.
Claude gave correct advice, Grigorev ignored it, and the system executed exactly what it was configured to execute. The problem wasn’t the AI. The problem was the permissions.