I think my honest to god feeling right now, is that AI changes the skill set for development so much, that a lot of engineers, even senior ones, are no longer qualified to do these jobs anymore.
AI's been exposing bad process, bad security, bad repo and deployment hygiene at a breadth and depth we simply haven't seen before. The industry wasn't, and still isn't ready.
I've been keenly following every one of these stories, ever since that first "Gemini ate prod," post last year, and the pattern I'm seeing is that nearly all of these cases could have been prevented by engineers... simply being better engineers.
The sheer number of times Claude has been able to deprovision a production database like this, while also destroying backups isn't proof of AI malfeasance, confession or otherwise.
Universally, it's human error of some kind.
Take this case:
Claude didn't have keys, so it looked them up in the user's sandbox.
It found them, because the user left enough unsecured authority lying around to murder the entire company.
Backups were served from the same instance as the database.
That's happened often enough, that it could be a bogus provider setting. But, on the other hand, it's absolutely something the user should have noticed and reconfigured.
If your backups are being served from the same volume that you're backing up... you don't have backups.
Thing is, Claude never should have been in a position to touch provisioning in the first place. Allowing an agent to run an entire CI/CD pipeline from top to bottom with elevated permissions and real time access is flatly irresponsible.
The PocketOS case is a five layer cake of incompetence.
And what's worse is that they didn't learn anything from it. First reaction was to ask Claude to confess to wrongdoing, and an immediate posting on X.
So this will almost certainly happen again.