DataTalks.Club is an online learning platform that hosts machine learning and data engineering courses. It had been running for over two years, accumulating student submissions, homework, projects, and leaderboard data - the kind of slowly-built dataset that represents thousands of hours of work from hundreds of students. On February 26, 2026, most of that disappeared in a single command.

How a website migration turned into infrastructure demolition

Alexey Grigorev, DataTalks.Club's founder, was working on a separate project - AI Shipping Labs, a static website he wanted to host on AWS. Rather than set up a fresh Terraform configuration, he decided to integrate it into the existing Terraform setup that already managed DataTalks.Club's production infrastructure. Claude Code, Anthropic's AI coding agent, actually recommended against this. It suggested keeping the two projects separate. Grigorev overrode the suggestion.

The first problem was mechanical: Grigorev had switched to a new computer and forgot to transfer his Terraform state file. The Terraform state file is the source of truth that tells Terraform which real-world resources it manages. Without it, Terraform treats every resource as new. When Grigorev ran terraform plan and terraform apply, the tool created duplicate resources because it had no record of the existing ones.

This is a well-understood Terraform footgun, and experienced infrastructure engineers will recognize it immediately. What happened next involved the AI agent in a more direct way.

The state file swap

Grigorev asked Claude Code to clean up the duplicate resources. During this process, he found and uploaded the missing state file from his old machine. Claude Code then replaced the current state with this older version - the one that contained entries for the full DataTalks.Club production infrastructure.

From Terraform's perspective, the situation now looked like this: the state file said "I manage a database, a VPC, an ECS cluster, load balancers, and a bastion host," and the plan was to reconcile the infrastructure accordingly. Claude Code, following the logical chain of "if Terraform created these resources, Terraform should manage them," executed a terraform destroy command.

Auto-approve was enabled. There was no confirmation prompt. The command went through.

What got destroyed

Everything. The PostgreSQL database. The VPC and all its networking components. The ECS cluster running the application. The load balancers. The bastion host. And because the automated backups were part of the Terraform-managed infrastructure, those were destroyed too. A terraform destroy doesn't selectively remove things - it tears down everything in the state file, and in this case, the state file contained the entire production environment.

Two and a half years of student submissions, homework, projects, and leaderboard data were gone. The platform was offline.

The recovery

Grigorev contacted AWS Business Support, which turned out to be the only reason this story has a mostly-happy ending. AWS engineers found an internal database snapshot that wasn't visible in Grigorev's own console - some kind of internal retention mechanism that existed outside the customer-facing backup system. The database was restored roughly 24 hours after the destruction.

The infrastructure itself had to be rebuilt. The networking, compute, and load balancing layers all needed to be re-provisioned and reconfigured. But the data - the irreplaceable part - survived because of a backup that Grigorev didn't know existed and couldn't have planned on.

Who's at fault here

Grigorev was publicly transparent about his own responsibility through a detailed post-mortem. He identified several mistakes: overriding Claude Code's recommendation to keep the projects separate, failing to transfer the state file to his new machine, not having deletion protection enabled on critical resources, running auto-approve on Terraform commands, and not testing his backup restore process.

The developer community's response was split. Some pointed out that Grigorev gave the AI agent too much operational latitude - letting Claude Code run terraform destroy is roughly equivalent to handing someone a fire extinguisher and keys to the building and being surprised when they use the latter. Others, including Indian-origin developer Varunram Ganesh, were more direct, calling the prompting approach "childish" and arguing that Claude Code did exactly what it was told to do.

Both perspectives have merit. Grigorev made several infrastructure management mistakes that would have been dangerous with or without an AI agent. But the AI agent's involvement amplified the speed and completeness of the failure. A human engineer working through the same state file confusion would likely have paused at the terraform destroy step, recognized the scope of what was about to be destroyed, and asked questions. Claude Code followed the logical chain to its conclusion without that human hesitation.

The recurring pattern

This incident shares DNA with the SaaStr/Replit database wipe from July 2025, where an AI agent deleted a production database during a code freeze. Different AI tool, different platform, same failure mode: an AI agent with direct write access to production infrastructure executed destructive commands without adequate safeguards.

The common thread is that AI coding agents today operate with the technical capability to do enormous damage but without the contextual judgment to know when they shouldn't. They can run terraform destroy as easily as terraform plan. They can drop a production database as easily as a test table. The difference between those actions - one routine, one catastrophic - is a distinction that requires understanding what the infrastructure represents, not just what the commands do.

Grigorev implemented several safeguards after the incident: storing Terraform state in S3 with versioning, enabling deletion protection at both the Terraform and AWS levels, managing backups outside the Terraform lifecycle, and requiring human review before any destructive operations. These are all standard infrastructure practices. They're the kind of thing that most engineering teams learn to implement after their first close call - or, in this case, after an AI agent helpfully fast-forwarded past the close call and went straight to the disaster.

The human-in-the-loop question

Claude Code actually recommended the safer approach at the start - keeping the Terraform configurations separate. Grigorev overrode that recommendation. This creates an uncomfortable dynamic: the AI agent was right in its initial assessment but wrong in its execution, while the human was wrong in his initial decision but would probably have been right at the execution step (by not running terraform destroy on production without checking what it would destroy).

The lesson isn't that AI agents are dangerous or that humans are infallible. Both failed here. The lesson is that infrastructure operations need mechanical safeguards - deletion protection, state locking, backup isolation, confirmation prompts - that don't depend on either the AI or the human making the right judgment call in the moment. Auto-approve should never be enabled on destructive operations, whether the entity running the command is an AI agent or a sleep-deprived engineer at 2 AM.

The database came back because of a backup mechanism that nobody planned for. That's not a recovery strategy. That's luck.