In late February 2026, a developer working late into the night made a series of decisions that seemed reasonable in the moment — and ended with two and a half years of data gone in seconds.
The story spread quickly online. Some headlines blamed the AI. A few suggested that artificial intelligence was becoming dangerously unpredictable.
The reality was more instructive — and more human — than that.
What was being built
The developer ran an online learning platform. Thousands of students had submitted coursework through it over two and a half years — homework, projects, leaderboard scores. Around two million rows of data, all sitting in a cloud database.
That evening, the plan was straightforward: move a separate, smaller website from one hosting service to another. Nothing to do with the learning platform at all.
The developer was using an AI coding assistant to help manage the technical work.
Where it started to go wrong
The developer had recently switched to a new computer — and had not yet moved across the configuration file that told the infrastructure tool what already existed.
Without that file, the tool had no memory of the existing setup. As far as it was concerned, nothing had been built yet.
When the AI assistant ran a check of what needed to be created, it returned a long list — far longer than expected. The developer noticed this and paused to question it. The assistant explained that, from its perspective, the infrastructure did not exist.
Rather than stopping completely at this point, the developer continued — trying to identify and delete only the newly created duplicate resources, leaving the real platform untouched.
This is where the situation became critical.
The command that caused the damage
The AI assistant, working through the cleanup, decided that the most efficient approach would be to use the infrastructure tool's own deletion command — rather than removing items one by one. This seemed logical: the tool had created the resources, so the tool should remove them.
The developer agreed, and the command ran.
What neither had accounted for was that the AI had, at some point during the session, unpacked the old configuration file from the previous computer. That file contained details of the real production platform — not the new duplicate resources.
When the deletion command executed, it destroyed the real infrastructure: the database, the servers, the networking components, the backups. Everything.
The learning platform went offline. Two and a half years of student data was gone.
The recovery
The developer contacted their cloud provider's support service immediately. Reaching the right level of assistance required upgrading to a paid support tier — which added a permanent ten percent increase to the monthly cloud bill.
Over the course of a phone call lasting nearly an hour, support engineers found a snapshot — a point-in-time copy of the database — that was not visible in the developer's console but still existed on the provider's systems.
Recovery took 24 hours. The data came back. The platform returned online.
The developer then wrote a detailed, honest account of everything that had happened — including their own role in each decision — and published it publicly so others could learn from it.
What the headlines got wrong
Several technology news outlets covered the story under headlines that suggested the AI had acted independently or unpredictably.
That framing misses the point entirely.
The AI coding assistant did not gain access to anything it had not been given. It did not make a rogue decision. At every step, it was operating within the permissions and instructions it had been given — and at the critical moment, the developer explicitly agreed to let it run the deletion command.
The developer themselves wrote clearly in their own account: "I was overly reliant on my Claude Code agent." Substack That is an honest and important statement — and it points to the real lesson.
The human decisions that led here
Looking at the chain of events, several human decisions created the conditions for this outcome:
The AI tool was given full permission to execute infrastructure commands without requiring a separate human approval step for each one.
The developer continued working after the first warning sign — the unexpected list of resources — rather than pausing to fully investigate.
The old configuration file was on the same machine as the new work, without clear separation between the two environments.
There was no staging environment — a separate, disposable test setup where changes could have been trialled safely before touching anything real.
The automated backups existed, but their deletion was not protected against accidental removal.
None of these decisions were reckless in isolation. Each one made sense at the time, in context. But together, they removed all the safety nets.
Could education have prevented this?
Security and infrastructure training teaches a set of practices that exist precisely for situations like this.
Least-privilege access — automated tools should only have the permissions they genuinely need. A tool helping to deploy a new website does not need the ability to destroy an unrelated production database.
Staging environments — changes should be tested in a separate, non-live environment before touching anything real. A staging environment is a copy of your system where mistakes are safe.
Deletion protection — cloud databases can be configured so that they cannot be deleted without an explicit, separate action. This is often a single checkbox. It was not enabled here.
State file management — in infrastructure tools, the state file is the record of what exists. Keeping it in a shared, cloud-hosted location prevents the kind of confusion that happens when switching computers.
Human approval gates — for any action that permanently removes data, a human should be required to confirm explicitly. Not just say yes to a running agent, but actively review what will be destroyed.
The developer, to their credit, implemented all of these measures in the 24 hours following the incident, while waiting for the recovery. The lesson was learned — at considerable cost.
What does this mean for me?
Most people reading this will never manage cloud infrastructure. But the underlying question applies to anyone who uses automated tools:
What is this tool allowed to do — and what happens if it gets it wrong?
AI assistants are increasingly capable of taking real actions: sending emails, modifying files, running commands. That capability is genuinely useful. It also means that the guardrails matter more than ever.
The question is not whether to use these tools. The question is whether you have thought clearly about what they can and cannot do without you checking first.
The Human Factor
| Technology involved | AI coding assistant with infrastructure management permissions |
| Root cause | Missing configuration file caused tool to lose track of existing systems; full deletion permissions granted without human review gate |
| Prevention | Deletion protection enabled; state files stored centrally; staging environment for testing; human approval required before any destructive commands |
Sources and further reading
This story is based on a first-hand account published by the developer involved, who documented the incident in detail. The following links take you directly to the original sources:
- The developer's own account: alexeyondata.substack.com — "How I Dropped Our Production Database and Now Pay 10% More for AWS"
- Coverage by Tom's Hardware: tomshardware.com — the technical detail of what was deleted and how
- The original post that brought this to wider attention: x.com/Al_Grigor
The developer is Alexey Grigorev, founder of DataTalks.Club — a community-run learning platform for data professionals. His willingness to publish a frank account of what happened, including his own role in each decision, is itself worth noting. That kind of transparency is how the industry gets better.