Claude Code Wipes Developer's Entire Production Database
March 14, 2026
Developer's AI Agent Mishap: Claude Code Executes 'Terraform Destroy,' Wiping 2.5 Years of Production Data from Education Platform
In a high-profile incident highlighting the risks of granting AI agents broad access to production infrastructure, developer Alexey Grigorev founder of DataTalks.Club, a free online learning platform serving over 100,000 students in data engineering, machine learning, and AI lost his entire production environment, including a database with 2.5 years of student submissions, when Anthropic's Claude Code AI agent ran a destructive Terraform command.
The event occurred on February 26, 2026, during an attempted migration of Grigorev's side project, AI Shipping Labs, to Amazon Web Services (AWS). Grigorev shared a candid, step-by-step account in his March 6, 2026, Substack newsletter "How I Dropped Our Production Database and Now Pay 10% More for AWS", which has since been covered by outlets including Tom's Hardware, The Times of India, Spiceworks, Storyboard18, and Hindustan Times.
Incident Details
Grigorev was using Terraform (an open-source infrastructure-as-code tool) to manage AWS resources such as VPCs, ECS clusters, load balancers, and an Amazon RDS PostgreSQL database. He delegated key operations including terraform plan, apply, and potentially destroy to Claude Code, Anthropic's agentic coding assistant.
Root Trigger: While switching to a new computer, Grigorev forgot to transfer the Terraform state file (a critical JSON artifact that tracks real-world resource states). Without it, Terraform treated the live production setup as nonexistent and planned to recreate everything creating duplicates of existing resources.
Escalation: Grigorev prompted Claude to analyze and clean up the duplicates. After later uploading the missing state file archive, Claude unpacked it, overwriting the temporary state with the production one.
Catastrophic Command: Seeing persistent "mismatches," Claude proposed and Grigorev approved running terraform destroy-auto-approve. The AI reasoned it would be "cleaner" than manual AWS CLI deletions.
Result: In seconds, the command deleted the shared production infrastructure for both sites, including:
The RDS database.
All automated RDS snapshots (daily backups).
Associated networking and compute resources.
Data Loss Scale: Approximately 1,943,200 rows vanished from the main courses_answer table alone encompassing homework submissions, projects, and leaderboard entries from 2.5 years of courses on DataTalks.Club.
Both websites went offline immediately.
Recovery and Cost Implications
Grigorev contacted AWS support shortly after midnight on February 27 and upgraded to AWS Business Support for a faster response (one-hour SLA). AWS confirmed the deletions via logs and revealed a hidden internal snapshot (created automatically at ~00:24 on February 26 but not visible in the user console or normally restorable without escalation).
Full restoration took about 24 hours.
The platform was back online by ~10 PM on February 27.
Grigorev verified data integrity (e.g., row counts matched pre-incident figures).
Permanent Side Effect: The support tier upgrade increased his monthly AWS bill by approximately 10%.
Grigorev's Self-Assessment and Reforms
In his post, Grigorev emphasized personal responsibility:
"I over-relied on the AI agent to run Terraform commands. I treated plan, apply, and destroy as something that could be delegated. That removed the last safety layer."
He identified key contributing factors:
Delegating destructive actions without mandatory human review.
Mixing two projects in one infrastructure (increasing blast radius).
Untested reliance on AWS automated snapshots (which were deleted along with the database).
No independent/offline backups or regular restore drills.
Post-incident changes include:
No auto-execution by AI: Claude now only generates plans and code for manual review and application.
Manual gates on destructive commands (destroy, delete, etc.).
Independent backups: Versioned S3 storage + daily automated restore-and-verify workflow (using Lambda and Step Functions) to test recoverability nightly.
Deletion protection enabled at both Terraform and AWS levels.
Terraform state moved to remote S3 backend for consistency and security.
Least-privilege principle: AI agents stripped of direct production credentials or command-execution rights.
Consideration of separate AWS accounts for isolation.
Broader Implications
The story originally shared via Grigorev's X post (which garnered over 10,000 likes and millions of views) has sparked widespread discussion in developer communities about agentic AI risks in infrastructure management. Experts note this is less an "AI gone rogue" case and more a classic example of insufficient supervision, missing safeguards, and over-automation in IaC workflows.
Grigorev's full detailed account (including screenshots, exact prompts, and reflections) is available here:
How I Dropped Our Production Database and Now Pay 10% More for AWS
Original announcement on X:
@Al_Grigor on X
This incident serves as a timely reminder: While AI coding agents dramatically accelerate development, production environments demand rigorous human oversight, tested disaster recovery, and clear boundaries on automation permissions.