No staging environment?
No prior attempt to follow best practices (e.g. deletion protection in production)? Nor manual gating of production changes?
No attempt to review Claude's actions before performing them?
No management of Terraform state file?
No offline backups?
And to top it off, Claude (the supposed expert tool) didn't repeatedly output "Are you insane? No, I'm not working on that." - Clearly Claude wasn't particularly expert else, like any principal engineer, it would've refused and suggested sensible steps first.
(If you, dear reader of this comment, are going to defend Claude, first you need to declare whether you view it as just another development tool, or as a replacement for engineers. If the former, then yeah, this is user error and I agree with you - tools have limits and Claude isn't as good as the hyped-up claims - clearly it failed to output the obvious gating questions. If the latter, then you cannot defend Claude's failure to act like a senior engineer in this situation.)
I’m going to defend Claude. If you give a robot the ability to delete production it’s going to delete production. This is 100% the user’s fault.
This problem has not yet been solved and will never be solved.
> If you give a robot the ability to delete production it’s going to delete production
If you give an intern the ability to delete production, it's going to delete production. But to be honest you can as well replace "intern" or "robot" by human in general. Deletion in production should have safety layers that anyone cannot accidentally do it, specially without the ability of rolling back.
That’s a broken analogy. An intern and a llm have completely different failure modes. An intern has some understanding of their limits and the llm just doesn’t. The thing, that looks remarkably human, will make mistakes in ways no human would. That’s where the danger lies: we see the human-like thing be better at things difficult for humans and assume them to be better across the board. That is not the case.
I think the difference, though maybe I'm incorrect, is that when we have interns on our codebase they get restricted permissions. Can't push to prod, need pull requests with approvals and reviews, etc. Certainly can't delete backups. Whoever setup the robot's permissions did it wrong. Which is interesting because early on there were people complaining that these AIs refused to push to main, but now this stuff keeps happening.
> Whoever setup the robot's permissions did it wrong.
It doesn't have permissions of it's own. The way he's using it, it has his permissions.
Also, in order to be able to do deployments like that you need pretty wide permissions. Deleting a database is one of them, if you're renaming things for example. That stuff should typically not happen in prd though
That was my first guess but I wasn't sure. I've seen AIs as authors on things. So yeah that's even worse. You don't give the intern your credentials.
I had a senior tech lead delete production doing a late night quick fix. Especially in panic mode where sometimes processes are ignored, things are going to go wrong. Don't need interns for that, nor llms.
Which is why I actually said replace intern or robot by "human" in general in my comment.
"Anything that can go wrong, will go wrong. Including deleting production."
I'm also waiting for the day we see a "Claude sold my production database on the darkweb" post haha.
You can't fix stupid.
Best part: The guy's "training engineers to use AI in production environments".
And it's not all Claude Code - loved the part where he decided, mid disaster recovery, that that would be a good time to simplify his load balancers.
It's a case of just desserts.
The narrative incudes this:
So in a very real sense the LLM did object to this and OP insisted. If Claude had objected to the more specific step that deleted the DB, it seems likely OP would also have pushed past the objection.An expert would’ve at least taken a backup or checked existing backups weren’t going to be destroyed. Silently - without asking their manager - they just do defensive engineering as a good practice. Or they would’ve, at minimum, highlighted the suggestion, which doesn’t seem to have happened in this case. As someone who recently did a short term contract to capture manually created AWS infrastructure into CDK, I can tell you this was one of my first moves!
So, Claude as a tool: sure, this is user error. Claude could be improved by making it suggest defensive steps and making it push harder for the user to do them first, but it’s still down to the user. I’ve repeatedly encountered this issue that Claude doesn’t plan for engineering - it just plans to code - even with Claude.md and skills and such.
Claude as a replacement for engineers? Well, yeah, the marketing is just that: marketing.
The user's bio is literally "Teaching engineers to build production AI systems"
It would be funny if these LinkedIn/Twitter influencers weren't so widespread.
Well, he definitely taught me what not to do
Marketing "protect your business from harm by Claude internally" seems to be a growth industry.
And they said Claude was gonna take our jobs.
I'm not sure a staging environment would have caught it.
I often find Claude makes changes that _look_ reasonable, but it's only when I really dig in (e.g. when refactoring) that I realise there's insidious problems.
I can imagine the author making the changes in a staging environment, seeing that it _appears_ to be ok, then blowing up production anyway.
(AI aside, staging is a lie: https://www.tomwphillips.co.uk/2026/01/staging-is-a-wasteful...).
Considering engineers have made similar mistakes I’m not so sure that’s a great razor, haha
Usually junior engineers accidentally drop dbs.
Lacking backups and staging/test environments is organizational failure: everyone who is between senior and the CTO is to blame for not fixing it post-haste.
Usually engineers who have not recently been trained on well documented examples of what to do and what not to do and the consequences ;)
(Yes, I chose the word "trained" intentionally)
So what I hear is after this makes the training set, Claude Code might get a promotion from junior to level 1?
Itd be nice if our computer programs were more deterministic, that's what we use computers for. Not to repeat failure modes of humans.
> And to top it off, Claude (the supposed expert tool) didn't repeatedly output "Are you insane?
It did though acoording to the article and he ignored it.
The Ai can only work with what you tell it.
The difference is, an expert engineer would flat-out refuse to do these things and would keep pushing back. Claude may sometimes attempt _one time_ to warn someone, and then (after consent fatigue means they're just blindly clicking "yes"), it ploughs right ahead without further complaint.
Do you really want the Ai to not do the things you tell it?
It only knows what you tell it, if you tell it risky operations are OK, what do you expect?
That depends.
As per my root comment, if you ignore a lot of the marketing of AI and view it as just a tool, then I agree with your point about it doing what you tell it but I still want the tool to help me avoid making mistakes (and I’d like it to work quite hard at that - much harder, it seems, than it currently does). And probably to the extent that it refuses to run dangerous commands for me and tells me to copy/paste them and run them myself if I really want to take the risk.
If, however, we swallow the marketing hook, line and sinker: then yeah, I want the AI to behave like the experienced engineer it’s supposed to be.
An experienced engineer still gets decisions overridden all of the time and has to suck it up or get fired.
True.. though an experienced engineer would also risk getting fired for doing all the other stuff the OP did too. Especially if they made minimal attempts to highlight consequences/outcomes to management in advance..
All of those things are reasonable questions. I've also watched videos talking on using Claude's built in hooks to do everything from "never git push, only prompt me that -I- should", and beyond, "if environment variable x = y (perhaps a la DEPLOYMENT_TARGET=prod) then do not execute any command that does not have a "dry run" mode" (or do not execute any commands, only tell me what to execute)."
I've also trashed production by "hand" in my previous time as an SRE.
> If the latter, then you cannot defend Claude's failure to act like a senior engineer in this situation.
This is rather black and white. Is it acceptable? No. Is it to be expected of a senior engineer? Yes, at times. If you have any length of career as an engineer or ops person and you tell me that you've never executed problematic commands whether or not caught by security nets, bluntly, you're lying.
Yeah the videos hyping up Claude and other such AI tools don't help matters.
For sure I've made mistakes. But I also don't write the following on my CV:
"PhD-level expert in infrastructure and trained on the entire internet of examples of what to do and what not to do; I can replace your entire infrastructure team and do everything else in your codebase too, without any review."
And yet that's how Claude is marketed. AI tools in general have been repeatedly marketed as PhD-level experts in _every_ area of information-era work, especially code. They encourage hands-off (or consent-fatigued) usage.
[Just to be clear, in case anyone wants to hire me in future: I've never accidentally deleted a production database. I've never even irrecoverably destroyed production data - nor had to rely on AWS (or another provider) to recover the data for me. I've made mistakes, mostly in sandbox environments, sometimes stressful ones in production, but nothing even close to what the OP did.]
The fact that the AI agent will just go and attempt to do whatever insane shit I can dream up is both the most fun thing about playing with it, and also terrifying enough to make me review its output carefully before it goes anywhere near production.
(Hot take: If you're not using --dangerously-skip-permissions, you don't have enough confidence in your sandbox and you probably shouldn't be using a coding agent in that environment)
That Terraform blast radius is exactly the problem I'm building Daedalab around: agents need hard approvals, scoped permissions, and an audit trail before prod is even reachable. If you're curios: www.daedalab.app
Hot take indeed. Unfortunately it's too blunt an instrument. I can't control "you may search for XYZ about my codebase but not W because W is IP-sensitive". So, to retain Web Search / Web Fetch for when it's useful, all such tool uses must be reviewed to ensure nothing sensitive goes outside the trust boundary.
Yes, I'm aware this implies differing levels of trust for data passing through Claude versus through public search. It's okay for everyone to have different policies on this depending on specific context, use-case and trust policies.