When humans were writing the majority of enterprise code and fielding the majority of cyber attacks, we measured data loss risk based mainly on human impact. Recovery was, and is still for most teams, considered an insurance policy: something you set up, test once a year, and hope you'd never need.
Agentic AI has changed the math.
It is accelerating the pace of nearly every operation within the enterprise, and it's doing so on both sides of the equation at once. Engineering teams are shipping more code, faster. Attackers are finding more vulnerabilities and scaling campaigns with tools that didn't exist 12 months ago. If your data recovery infrastructure hasn't evolved, you're facing a real problem.
How AI has changed the recovery landscape
Eighty-four percent of developers use or plan to use AI coding tools, and nearly half of all code committed to GitHub in early 2026 was generated or substantially assisted by AI. At Eon, we use AI coding ourselves. For data categorization and ingestion, it's fast, consistent, and accurate in ways that would take a human team weeks to sift through. We trust it in production because it’s uniquely suited for pattern recognition. Ingestion and management of large volumes of structured data is an example of where AI is strongest today.
AI-assisted coding is a different story. The productivity gains are real and growing, but the tools are still early enough that human review is required. They introduce misconfigurations, accidental deletions, and schema-breaking changes at a pace that review processes haven't caught up to. We saw this on the largest stage late last year, when Amazon's own AI coding agent autonomously deleted and recreated a production environment, triggering a 13-hour outage. The bot had the same permissions as a human engineer. Rather than patching the issue, it decided the most efficient fix was to start from scratch. A Fortune report from March documented a growing list of similar incidents across the industry, including a developer whose AI agent destroyed a live production database, snapshots included, during a routine update.
Having spent years running disaster recovery at AWS, I watched a version of this pattern play out before, just slower. An engineering team would make a change, something would break, and we'd discover the backup either didn't cover the right resources or couldn't restore with the precision the business actually needed. What used to happen a few times a year is potentially happening a few times per month, because AI has increased both the volume and the velocity of changes hitting production systems. It’s the “good with the bad” within AI-enabled coding.
The cyber side is compounding this. Anthropic's release of Claude Mythos in April showed that AI can now autonomously identify thousands of zero-day vulnerabilities across every major operating system and web browser, and build working exploits without human involvement. The time between discovering a vulnerability and weaponizing it, which used to take skilled researchers days, is now measured in hours. Ransomware groups target backup infrastructure first because destroying recovery options before anyone knows an attack has started is what gives them leverage. AI-powered offensive tools make that playbook faster and harder to defend against, but not impossible.
Ultimately, AI-driven coding errors are creating more frequent internal data loss events, and AI-augmented cyber attacks are creating more sophisticated external ones. Both are accelerating, and both converge on the same timely question: Can your organization actually recover what it needs, when it needs it? The hard truth most CIOs are telling us, is not really.
Why "more backups" isn't the answer
The instinct is to just back up more and more often. But volume alone doesn't solve the problem if recovery is still slow and blunt.
If you can't pinpoint when a specific table was corrupted, restore a single record without spinning up an entire environment, or confirm whether your backup covers the new database your AI coding agent provisioned last week, then more frequent backups are just a more expensive version of the same complex and costly process. The frequency of your backups matters far less than the precision and speed of your recovery. (For databases in particular, it's exactly why we built this.)
Recovery at machine speed
Having humans manually tag every new asset, file, or schema change is an enormous effort at any pace, let alone the wild pace at which AI-driven development creates new resources today. This is where AI earns its keep on the recovery side: continuous discovery, classification, and policy enforcement across your entire environment, running in the background without manual intervention.
This gives teams the confidence to keep moving fast.
Incidents aren’t grounds to stop using AI coding tools, but they are a timely reminder of the importance of data recovery infrastructure, especially for enterprises operating in the cloud. Mistakes will always be a factor to mitigate, but today they happen at a new velocity. When an AI agent misconfigures a database or an attacker encrypts a production system, teams need to search across their entire backup estate, identify exactly what was affected, and restore only that, at the file, table, or record level. A full-environment rebuild is too costly and complex to be entertained. The capability to restore less, with more precision, means better recovery without adding cost.
At Eon, recovery is something we think about every day. It's what I spent years working on at AWS, and it's what led Ron, Gonen, and me to build this company. The gap between how fast enterprises operate and how fast they can recover has never been wider. If your team builds at machine speed, your recovery needs to keep up.
