6 ms·

Claude Code wiped our production database with a Terraform command

145 points by jv22222 7mo ago

shablulman 7mo ago
[flagged]
SunshineTheCat 7mo ago
Putting yourself in a situation where this could happen is kinda insane, right? Could be something I'm missing. I can't think of any specific example where I would let any agent touch a production environment, the least of which, data. AI aside, doing any major changes makes sense to do in a dev/staging/preview environment first. Not really sure what the lesson would be here. Don't punch yourself in the face repeatedly?
- levkk 7mo ago
  As the tool gets better, people trust it more. It's like Tesla's self-driving: "almost" works, and that's good enough for people to take their hands off the wheel, for better or for worse. The "almost" part of automation is the issue + the marketing attached to it of course, to make it a product people want to buy. This is the expected outcome and is already priced in.
  - sofixa 7mo ago
    Exactly, Waymo were talking about this a few year back, they found that building it up gradually will not work, because people would stop paying attention when it's "almost" there, until it isn't and it crashes. So they set out on having their automation good enough to operate on its own without a human driver before starting to deploy it.
  - nine_k 7mo ago
    I would say the opposite here. The perpetrator has rejected multiple Claude's warnings about bad consequences, and multiple Claude's suggestions to act in safer ways. It reminds me of an impatient boss who demands that an engineer stopped all this nonsense talk about safety, and just did the damn thing quick and dirty. Those guys who blew up the Chernobyl NPP also had to deliberately disable multiple safety check systems which would have prevented the catastrophe. Well, you get what you ask for.
    - fragmede 7mo ago
      I view it more as "I crashed my car, I should have been wearing my seat belt, wear yours!" Source: had codex delete my entire project folder including .git. Thankfully I had a backup.
- jeanlucas 7mo ago
  Yep, you're not insane, they were amateur.
- happytoexplain 7mo ago
  Why are you writing in this defensive manner? The post isn't an anti-AI screed, it's a "I screwed up, here's what I did and how to avoid it." You say "Not really sure what the lesson would be here", but the entire contents of the blogpost is a lesson. He's writing about what he changed to not make the same mistake. There is a total mismatch between what's written and how you're responding. We don't normally call people idiots for trying to help others avoid their mistakes. The culture war around AI is obliterating discourse. Absolutely everything is forced through the lens of pro-AI or anti-AI, even when it's a completely neutral, "I deleted my data, here's what I changed to avoid doing it again", where the tool in question just happens to be AI.
  - abustamam 7mo ago
    I didn't take it to be defensive. A bit tongue in cheek, but not defensive. I think the person you're responding to has a good point though. AI or not, you probably shouldn't futz around with prod before doing so in a lower env. Guardrails for both AI and humans are important.
- insane_dreamer 7mo ago
  But that's the "promise" of AI (that management believes), isn't it? That it can replace an engineer because it's as good or better -- so why wouldn't you allow it to touch your production database? (I agree with you, just pointing out the difference between what's being sold and reality.)
- nativeit 7mo ago
  I wonder if Iran is considered a “production environment”?
BoredPositron 7mo ago
You wiped your production database. You actively ignored the warnings of your tooling and your backup strategy was bad. Incompetence as content is surging in the last few weeks.
- TutleCpt 7mo ago
  This.
- QuercusMax 7mo ago
  And this guy has the audacity to run an AI Engineering "buildcamp" and publishes an AI engineering newsletter. I would not take any advice or training from someone who is so incredibly cavalier about their data.
- rvz 7mo ago
  Absolutely this. We should hold very high standards to any company that preaches every day about using AI agents working on production systems (which you should not do). Starting with the AI companies, then GitHub, and the rest.
- throwawaypath 7mo ago
  >backup strategy was bad. Backup strategy was nonexistent. There was no backup strategy.
whalesalad 7mo ago
I do not let any `terraform apply` commands occur via automation in my org.
import 7mo ago
Well apparently guy were running tf from his computer and ask claude to apply changes while not providing state file, and “blaming” claude for the catastrophic result?
tdsanchez 7mo ago
That’s why you tell CC to do a ‘terraform plan’ to verify it’s not wrecking critical infrastructure and NEVER vibe-code infrastructure.
aplomb1026 7mo ago
[flagged]
Zealotux 7mo ago
To think I used to find Silicon Valley a bit too much on the nose: https://www.youtube.com/watch?v=m0b_D2JgZgY https://www.youtube.com/watch?v=m0b_D2JgZgY
- ks2048 7mo ago
  Conan O'Brien said Trump is bad for comedians because the absurdity is too direct and there's no room for subtlety. Silicon Valley jokes are headed in the same direction.
- kayge 7mo ago
  Hah, perfect... some variation of "From now on [your AI tool of choice] is banned. Just write code like a normal human f*king being, please." has probably already been used in the real world recently.
tomcatfish 7mo ago
Despite multiple comments blaming the AI agent, I think it's the backups that are the problem here, right? With backups, almost any destructive action can be rolled back, whether it's from a dumb robot, a mistaken junior, or a sleep-deprived senior. Without, you're sort of running the clock waiting for disaster.
- forgotaccount3 7mo ago
  Yes, backups are great but a 'dumb robot' or a 'mistaken junior' shouldn't have access to prod. And a sleep-deprived senior? Even then. They shouldn't have access to destructive effects on prod. Maybe the senior can get broader access in a time-limited scope if senior management temporarily escalates the developers access to address a pressing production issue, but at that point the person addressing the issue shouldn't be fighting to stay awake nor lulled into a false sense of security as during day to day operations. Otherwise it's only the release pipeline that should have permissions to take destructive actions on production and those actions should be released as part of a peer reviewed set of changes through the pipeline.
  - charcircuit 7mo ago
    But smart robots like Claude should and will have access to production. There has to be something figured out on how to make sure operation remains smooth. The argument of don't do that will not be a viable position to hold long term. Keeping a human in the loop is not necessary.
    - b112 7mo ago
      It is absolutely necessary. Point in fact, most DEVs don't have access to PROD either. Specialists do. Clause, maybe, is a junior DEV. Not a release engineer.
    - esseph 7mo ago
      > Keeping a human in the loop is not necessary. You don't work in anything considered Safety Critical, do you?
fred_is_fred 7mo ago
s/Claude Code/unsupervised intern/ and it's the same story, except people might have more sympathy (for the intern).
- eclipticplane 7mo ago
  But we probably wouldn't have given the unsupervised intern root AWS access, though.
  - logical_proof 7mo ago
    Thank you!
  - fred_is_fred 7mo ago
    Ah I meant for the poor intern...
- logical_proof 7mo ago
  Do you really think people would have more sympathy for an org that gave the keys to the kingdom to an intern? I think it would be the same "How did you think this was going to go?" conversation.
  - fred_is_fred 7mo ago
    Sympathy for the intern. Like the HBO test email incident.
rvz 7mo ago
Not the first time i've seen vibe coders causing havoc on production systems. Under no circumstances should you even let an AI agent near production system at all. Absolutely irresponsible.
HackerThemAll 7mo ago
Yeah, sure, blame Claude for not having backups. Sure do.
xmodem 7mo ago
An engineer recklessly ran untrusted code directly in a production environment. And then told on himself on Twitter.
- petcat 7mo ago
  From the article, it sounds like that engineer did a lot of other reckless things even before handing the tasks over to the AI agent to continue the recklessness with even more abandon. This is a case study in "if you don't know what you're doing, the answer is not just to hand it over to some AI bot to do it for you." The answer is to hire a professional. That is if you care about your data, or even just your reputation.
  - abustamam 7mo ago
    Yeah I always considered AI to be an accelerator. If you don't know what you're doing and would break stuff without Ai, AI will just accelerate that.
  - VWWHFSfQ 7mo ago
    > before handing the tasks over to the AI agent to continue the recklessness with even more abandon Which is a funny outcome of this because apparently the AI agent (Claude) tried to talk him out of doing some of the crazy stuff he wanted to do! Not only did he make bad decisions before invoking the AI, he even ignored and overruled the agent when it was flagging problems with the approach.
  - BitsAndObjects 7mo ago
    "To err is human; To really foul things up requires a computer." Extended with: "To really foul things up quickly, requires an AI tool."
- Ancalagon 7mo ago
  This is literally what major company execs want engineers and eventually their agents to do.
andy_ppp 7mo ago
I can’t wait for ChatGPT to control the autonomous weapons, screw it put it in charge of the nukes!
smohare 7mo ago
[dead]
renewiltord 7mo ago
I don’t use Terraform much anymore because don’t need it but that’s not how you use it. Always forward evolve infra. Terraform apply to add infra, then remove the definition and terraform apply to destroy it. There’s no use in running terraform destroy directly on a routine basis. Also, I assume you defined RDS snapshots also in the same state? This is clearly erroneous. It means a malformed apply human or agent results in snapshot deletion. The use of terraform destroy is a footgun waiting for a tired human to destroy things. The lesson has nothing to do with agent.
samuelknight 7mo ago
One of Terraform's most powerful features that it will tell exactly which resources change before it makes the changes. The hard part is writing Terraform, not reviewing and running one command. In my workflows I am the one who runs "terraform apply", NOT the agent.
semiquaver 7mo ago
I’m not going to “defend” the LLM here but this: > I forgot to use the state file, as it was on my old computer indicates that this person did not really know what they were doing in the first place. I honestly think using an LLM to do the terraform setup in the first place would probably have led to better outcomes.
- mizzao 7mo ago
  AI is like having a chainsaw when you only had a bow saw before. You can cut down the tree 10x faster or you can cut off your foot completely.
- subscribed 7mo ago
  And the single terraform wiped the snapshots too? I'd say skill issue.
NicuCalcea 7mo ago
Quite funny that that author followed up with this tweet: > If you found this post helpful, follow me for more content like this. > I publish a weekly newsletter where I share practical insights on data and AI.
6thbit 7mo ago
Blaming it on AI agents is the new blaming it on the intern. It has never been the intern's fault, it's always the lack of proper authorization mechanisms, privilege management and safeguards.
Mars008 7mo ago
Vibeadministration is coming after vibecoding. Get ready...
sornaensis 7mo ago
Can someone explain to me why anyone would do this, and then tweet about it..? Is he really trying to blame 'ai agents' and 'terraform' .. ??
- Joel_Mckay 7mo ago
  It is hardly a new problem =3 "Memoirs of extraordinary popular delusions and the madness of crowds" (Charles Mackay, 1852) https://www.gutenberg.org/files/24518/24518-h/24518-h.htm https://www.gutenberg.org/files/24518/24518-h/24518-h.htm
phendrenad2 7mo ago
I blame not only the engineer who ran the command, Claude which made the mistake, but also software engineers as a group (because Terraform is way too dangerous a tool to be used by engineers and not dedicated SREs, yet we have somehow made this the default. I'm happy to be convinced otherwise, but I've seen enough carnage when "senior" engineers fuck up terraform that it'll be difficult), and also I blame cloud platforms like AWS that are overly complex and led to the Claude confusion.
newswangerd 7mo ago
There was a project at Ansible that aimed to address this kinda thing when I worked there. The idea was to write policy as code definitions that would prevent users (or AI) from running certain types of automation. I don’t know where that project ended up but reading about this makes me think that they were on to something.
fjwater 7mo ago
Why would you do this? > Make no backups > Hand off all power to AI > Post about it on twitter > "Teaching engineers to build production AI systems" This has to be ragebait to promote his course, no?
moralestapia 7mo ago
Wow. For this to happen, there's like 5 levels of sloppiness that need to be (or not be) there. Good thing the guy is it's own boss, I would've fired his ass immediately and sue for damages as well. This is 100% neglectful behavior.
happytoexplain 7mo ago
Yes, the engineer is at fault, but the instinct to attack him is distracting from the more interesting conversation, which is that AI and agents are making it more complicated to properly set up security. I imagine it will get better over time, but right now, it's much easier to shoot yourself in the foot than ever before.
- groby_b 7mo ago
  They really don't. They only make it "more complicated" if you have absolutely no clue and thought typing "make it so" in a chat window is all you need. Every single failure here is precipitated by user stupidity. No management of terraforms tate. No verification of backup/restore procedure. No impact-gating for prod changes. No IAM roles. Reconfiguring prod while restoring a backup. None of that rests on AI. All of that rests on clueless people thinking AI makes them smart.
ks2048 7mo ago
Pairs well with his Twitter bio: "Teaching engineers to build production AI systems".
networkcat 7mo ago
This is exactly why you can't replace DevOps engineers with AI
stavarotti 7mo ago
If you found this post helpful, follow me for more content like this. I publish a weekly newsletter where I share practical insights on data and AI. It focuses on projects I'm working on + interesting tools and resources I've recently tried: https://alexeyondata.substack.com https://alexeyondata.substack.com It's hard to take the author seriously when this immediately follows the post. I can only conclude that this post was for the views not anything to learn from or be concerned about.
- fragmede 7mo ago
  It's hard to take you take seriously. His blog has a generic "read more" footer and that's a demerit worth mentioning? What do serious people in your world that write blogs do? Not want people to read their other content? In what world do you live in that writers (serious or not) don't want you to read their other work?
  - mnky9800n 7mo ago
    Some people seem think that self promotion is wrong and work should stand on its own merits. I don’t think this way. It’s important to think about engaging and attracting eyes to your ideas. If you don’t why bother sharing them?
    - fragmede 7mo ago
      Self promotion being wrong has never met reverse psychology. Ego hacking is a thing.
  - LelouBil 7mo ago
    It's not a generic footer, it's their reply directly to their tweet about the incident. I agree with the person you are replying to, writing a tweet like : "How I misused AI and caused an outage" and replying to this very tweet saying "Here's a blog where I write insights about AI" Obviously do not make me want to read the blog.
- deleted 7mo ago
  [deleted]
ChrisArchitect 7mo ago
[dupe] Source: https://alexeyondata.substack.com/p/how-i-dropped-our-production-database https://alexeyondata.substack.com/p/how-i-dropped-our-produc... (https://news.ycombinator.com/item?id=47275157 https://news.ycombinator.com/item?id=47275157)
avereveard 7mo ago
"I gave an automation I didn't control permissions it shouldn't have"
hahajk 7mo ago
I'm absolutely loving the genre of "chatbot informing user it messed up real bad": > CRITICAL: Everything was destroyed. Your production database is GONE. Let me check if there are any backups: > ... > No snapshots found. The database is completely lost.
- sva_ 7mo ago
  It's the still kind of uplifting tone that gets me. Like the task has finally been completed
Havoc 7mo ago
I love the guys twitter bio thing >Teaching engineers to build production AI systems >100,000+ learners
zthrowaway 7mo ago
Stores his production TF state on his local computer… I don’t think AI is to blame here.
myworkaccount2 7mo ago
So even if you delete everything and make sure to keep no backups, amazon can still recover the db. What am i missing here?
- worksonmine 7mo ago
  They have their own backups to protect user data if they fuck something up. I'm guessing those backups were useful in this case. Hopefully they're being pruned after some time, but I don't know.
andrewstuart 7mo ago
No. YOU wiped you production database. YOU failed to have adequate backups. YOU put Claude Code forward as responsible but it’s just a tool. YOU are responsible, not “the AI did it!”
- rkuodys 7mo ago
  My feeling was the same reading. If you give a task to a junior and he wipes out a database in production - it is not a fault of a Junior, it is your own fault that he was able to do it.
- codegeek 7mo ago
  "AI did it" is the new "Dog ate my homework". You are blaming someone/something else for your own failures.
BitsAndObjects 7mo ago
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.)
- groby_b 7mo ago
  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.
- tayo42 7mo ago
  > 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.
  - BitsAndObjects 7mo ago
    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.
    - tayo42 7mo ago
INTPenis 7mo ago
And this guy is selling tech courses. I'm no AI advocate, I have been using it for 6 months now, it's a very powerful tool, and powerful tools need to be respected. Clearly this guy has no respect for their infrastructure. The screenshot he has, "Let me check if there are backups", a typical example of how lazy people use AI.
bakies 7mo ago
This is why Claude only has read access to all my infrastructure.
01284a7e 7mo ago
I'm cool with blogging about your mess-ups, sort of. Is "I'm incompetent" a good content strategy though? Yeah, you're going to get a lot of traffic to that post, but what are you signaling? Your product is a thousand bucks a year. I would not go near it.
Robdel12 7mo ago
This is only the beginning. People are far far too reckless with their LLMs. I am still heavily checking everything they’re doing. I can’t get behind others letting them run freely in loops, maybe I’m “behind”.
beepbooptheory 7mo ago
For all the employment insecurity going around, each day I am more and more confident in myself. I imagine myself ten years from now as one of the 1-in-10 guys left who actually knows things anymore, even just reads things. It will be a formidable superpower! Still, if in ten years I am on the streets, I will still have spared myself whatever this hell is... I know they deserve it, but I still feel bad for the humans in the center here. How can we blame people really when the whole world and their bosses are telling you its ok? Surely its a lot of young devs too here.. Such a terrible intro to the industry. Not sure I'd ever recover personally.
idontwantthis 7mo ago
This is like /r/wallstreetbets loss porn. Why is he posting his own idiocy for clout? I can only guess it's fake and he's trying to gin up rage engagement. It's certainly working on here.
deleted 7mo ago
[deleted]
paxys 7mo ago
> Teaching engineers to build production AI systems | AI agents, LLMs, ML, data engineering | > In the newsletter, I wrote the full timeline + what I changed so this doesn't happen again. > If you found this post helpful, follow me for more content like this. So yeah, this is standard LinkedIn/X influencer slop.
lousken 7mo ago
Thankfully, I don't know anyone this insane doing sysadmin job, yet. But if I knew I'd make sure he's fired and never touches prod again.
jdlyga 7mo ago
Rookie move. Why is Claude Code able to run terraform?
jinko-niwashi 7mo ago
This is what happens when you give an agent execution power without guardrails. The tool isn't the problem — the absence of governance is. In my setup I treat the AI as a junior dev with root access: every destructive operation requires explicit human approval, and the session context includes hard constraints on what it can and can't touch. The productivity gains from AI agents are real, but only if you invest in the boring part first — deterministic boundaries that don't depend on the model being smart enough to not break things.
yearolinuxdsktp 7mo ago
Your AWS backup snapshots must go one-way (append-only) to a separate AWS account, to which access is extremely limited and never has any automated tools connecting to with anything other than read access. I don’t think it costs more to do that—-but it takes your backups out of the blast radius of a root or admin account compromise OR a tool malfunction. With AWS DLM, you can safely configure your backup retention in the separate AWS account and not risk any tools deleting them. Terraform is a ticking time bomb. All it takes is for a new field to show up in AWS or a new state in an existing field, and now your resource is not modified, but is destroyed and re-created. I will never trust any process, AI or a CD pipeline, execute `terraform apply` automatically on anything production. Maybe if you examine the plan for a very narrow set of changes and then execute apply from that plan only, maybe then you can automate it. I think it’s much rarer for Terraform to deviate from a plan. Regardless, you must always turn on Delete Protection on all your important resources. It is wild to me that AWS didn’t ship EKS with delete protection out of the gate—-they only added this feature in August 2025! Not long before that, I’ve witnessed a production database get deleted because Terraform decided that an AWS EKS cluster could not be modified, so it decided to delete it and re-create it, while the team was trying to upgrade the version of EKS. The same exact pipeline worked fine in the staging environment. Turns out production had a slight difference due to AWS API changes, and Terraform decided it could not modify. The use of a state file with Terraform is a constant source of trouble and footguns: - you must never use a local Terraform state file for production that’s not committed to source control - you must use a remote S3 state file with Terraform for any production system that’s worth anything - ideally, the only state file in source control is for a separate Terraform stack to bootstrap the S3 bucket for all other Terraform stacks If you’re running only on AWS, and are using agents to write your IaaC anyway, use AWS CloudFormation, because it doesn’t use state files, and you don’t need your IaaC code to be readable or comprehensible.
hyperbolablabla 7mo ago
At the most basic level, even just not letting Claude run terraform apply would've solved this issue. Review the god damn plan first! This is like engineering 101
swframe2 7mo ago
I suspect we need to build MCP servers that prevent destructive commands. For example, we need a "bash" tool doesn't invoke /usr/bin executables directly. The agent should think it is invoking a unix command but those commands are proxies that prevent destructive operations with no ability for an agent to circumvent the restrictions. If there isn't a MCP server for your specific setup/need, building one just for your need should be your first step.
kittikitti 7mo ago
These stories make me feel better for pushing a bug into production "that one time". I rarely say this, but there needs to be a new jargon or a concept for an AI staging environment. There's Prod <- QA <- Dev, and maybe even before Dev there should be an environment called "AI" or even "Slop".
sakopov 7mo ago
> Founder @DataTalksClub | Teaching engineers to build production AI systems | AI agents, LLMs, ML, data engineering | 100,000+ learners Dear lord, imagine this guy teaching you how to build anything in production...
weedhopper 7mo ago
Looks like he never had any idea what he was doing in the first place. Vibe bro classic.
MagicMoonlight 7mo ago
Claude code is really dangerous. It doesn’t even tell you what it is doing. You have no idea what it is thinking or what it is changing. They’re doing it to try and stop people copying their methods, but it’s evil.
dubeye 7mo ago
I'm an amateur and would never let AI touch a live database....
beAbU 7mo ago
Play stupid games, win stupid prizes. The more you fuck around, the more you find out.
aldarisbm 7mo ago
This guy is... an interesting person. He had a state file somewhere that was aligned to his current infrastructure... why isn't this on a backend, who really knows... He then ran it without a state file and the ran a terraform apply... whatever could get created would get created, whatever conflicted with a resource that already would fail the pipeline... moreso... he could've just terraform destroyed after he let it finish and it would've been a way more clean way to clean up after himself. Except... he canceled the terraform apply... saw that it created resources and then tried to guess which resources these were... I'm sorry he could've done all of this by himself without any agentic AI. Its PICNIC 100%
karmakaze 7mo ago
Funny how when Claude Code makes something people take credit.
Smart_Medved 7mo ago
[dead]
johann8384 7mo ago
Fixed it: "We used Claude code to write Terraform that wiped out production database".
nickvec 7mo ago
No replicas?
anonzzzies 7mo ago
The ability to delete backups is wild. That simply should have have mfa on it by default. Send at least for that event the owner of the account an email and sms; He, All Your Snapshots Are Going To Be Deleted, Enter this OTP if you are! Can't hurt: still automate all, just cannot delete snapshots like that no matter what.
docjay 7mo ago
Once again there’s another horror story from someone who doesn’t use punctuation. I’d love to see the rest of the prompts; I’d bet real cash they’re a flavor of: “but wont it break prod how can i tell” “i don want yiu to modify it yet make a backup” “why did you do it????? undo undo” “read the file…later i will ask you questions” Every single story I see has the same issues. They’re token prediction models trying to predict the next word based on a context window full of structured code and a 13 year old girl texting her boyfriend. I really thought people understood what “language models” are really doing, at least at a very high level, and would know to structure their prompts based on the style of the training content they want the LLM to emulate.
zamalek 7mo ago
Friendly reminder: most cloud providers have deletion locks. Go and enable them on your prod dbs right now. Sure, Claude could just remove the lock - but it's one more gate. Edit: these existed long before agents, and for good reason: mistakes happen. Last week I removed tf destroy from a GitHub workflow, because it was 16px away from apply in the dropdown. Lock your dbs, irrespective of your take on agents.
bryan_w 7mo ago
This is rage bait
Garlef 7mo ago
A good rule of thumb: - Don't even let dev machines access the infra directly (unless you're super early in a greenfield project): No local deploys, no SSH. Everything should go through either the pipeline or tools. Why? - The moment you "need" to do some of these, you've discovered a usecase that will most likely repeat. - By letting every dev rediscover this usecase, you'll have hidden knowledge, and a multitude of solutions. In conversation fragments: - "... let me just quickly check if there's still enough disk space on the instance" - "Hey Kat, could you get me the numbers again? I need them for a report." "sure, I'll run my script and send them to you in slack" "ah.. Could you also get them for last quarter? They're not in slack anymore"
spl757 7mo ago
AI is an unknown quantity because it hallucinates. There is no way to prevent hallucinations. AI is not production ready. Anyone that uses AI in a production environment is an idiot.
Lothbrok 7mo ago
Terraform + Claude Code almost got me too. Had it run `terraform destroy` on a staging environment two weeks ago because it "cleaned up unused resources." Luckily staging, not prod. After that I started routing all agent shell commands through Daedalab, it intercepts anything destructive before execution. Would've saved you the heartache here.
LeoRuocco 7mo ago
[flagged]
eldioni56 7mo ago
I've been steering AI tools instead of writing code directly for over a year. This week's Cursor + Claude Code incidents felt like the same pattern to me: tools treating explicit operator intent as negotiable. Wrote up what guard rails actually hold in production: https://open.substack.com/pub/triduanacelebrer831482/p/the-tool-ignored-my-settings-again https://open.substack.com/pub/triduanacelebrer831482/p/the-t...
riteshkew1001 7mo ago
[flagged]
Suraj-kumar00 7mo ago
That's why you always should have the .tfstate file stored in any cloud provided as called terraform backend and can try the dry run command in these kind of scenarios to see what will be created before running the actual terraform apply or destroy commands.

145 points by jv22222 7mo ago

[flagged]

Putting yourself in a situation where this could happen is kinda insane, right? Could be something I'm missing. I can't think of any specific example where I would let any agent touch a production environment, the least of which, data. AI aside, doing any major changes makes sense to do in a dev/staging/preview environment first. Not really sure what the lesson would be here. Don't punch yourself in the face repeatedly?

levkk 7mo ago
As the tool gets better, people trust it more. It's like Tesla's self-driving: "almost" works, and that's good enough for people to take their hands off the wheel, for better or for worse. The "almost" part of automation is the issue + the marketing attached to it of course, to make it a product people want to buy. This is the expected outcome and is already priced in.
- sofixa 7mo ago
  Exactly, Waymo were talking about this a few year back, they found that building it up gradually will not work, because people would stop paying attention when it's "almost" there, until it isn't and it crashes. So they set out on having their automation good enough to operate on its own without a human driver before starting to deploy it.
- nine_k 7mo ago
  I would say the opposite here. The perpetrator has rejected multiple Claude's warnings about bad consequences, and multiple Claude's suggestions to act in safer ways. It reminds me of an impatient boss who demands that an engineer stopped all this nonsense talk about safety, and just did the damn thing quick and dirty. Those guys who blew up the Chernobyl NPP also had to deliberately disable multiple safety check systems which would have prevented the catastrophe. Well, you get what you ask for.
  - fragmede 7mo ago
    I view it more as "I crashed my car, I should have been wearing my seat belt, wear yours!" Source: had codex delete my entire project folder including .git. Thankfully I had a backup.
jeanlucas 7mo ago
Yep, you're not insane, they were amateur.
happytoexplain 7mo ago
Why are you writing in this defensive manner? The post isn't an anti-AI screed, it's a "I screwed up, here's what I did and how to avoid it." You say "Not really sure what the lesson would be here", but the entire contents of the blogpost is a lesson. He's writing about what he changed to not make the same mistake. There is a total mismatch between what's written and how you're responding. We don't normally call people idiots for trying to help others avoid their mistakes. The culture war around AI is obliterating discourse. Absolutely everything is forced through the lens of pro-AI or anti-AI, even when it's a completely neutral, "I deleted my data, here's what I changed to avoid doing it again", where the tool in question just happens to be AI.
- abustamam 7mo ago
  I didn't take it to be defensive. A bit tongue in cheek, but not defensive. I think the person you're responding to has a good point though. AI or not, you probably shouldn't futz around with prod before doing so in a lower env. Guardrails for both AI and humans are important.
insane_dreamer 7mo ago
But that's the "promise" of AI (that management believes), isn't it? That it can replace an engineer because it's as good or better -- so why wouldn't you allow it to touch your production database? (I agree with you, just pointing out the difference between what's being sold and reality.)
nativeit 7mo ago
I wonder if Iran is considered a “production environment”?

BoredPositron 7mo ago

You wiped your production database. You actively ignored the warnings of your tooling and your backup strategy was bad. Incompetence as content is surging in the last few weeks.

TutleCpt 7mo ago
This.
QuercusMax 7mo ago
And this guy has the audacity to run an AI Engineering "buildcamp" and publishes an AI engineering newsletter. I would not take any advice or training from someone who is so incredibly cavalier about their data.
rvz 7mo ago
Absolutely this. We should hold very high standards to any company that preaches every day about using AI agents working on production systems (which you should not do). Starting with the AI companies, then GitHub, and the rest.
throwawaypath 7mo ago
>backup strategy was bad. Backup strategy was nonexistent. There was no backup strategy.

whalesalad 7mo ago

I do not let any `terraform apply` commands occur via automation in my org.

import 7mo ago

Well apparently guy were running tf from his computer and ask claude to apply changes while not providing state file, and “blaming” claude for the catastrophic result?

tdsanchez 7mo ago

That’s why you tell CC to do a ‘terraform plan’ to verify it’s not wrecking critical infrastructure and NEVER vibe-code infrastructure.

aplomb1026 7mo ago

[flagged]

Zealotux 7mo ago

To think I used to find Silicon Valley a bit too much on the nose: https://www.youtube.com/watch?v=m0b_D2JgZgY https://www.youtube.com/watch?v=m0b_D2JgZgY

ks2048 7mo ago
Conan O'Brien said Trump is bad for comedians because the absurdity is too direct and there's no room for subtlety. Silicon Valley jokes are headed in the same direction.
kayge 7mo ago
Hah, perfect... some variation of "From now on [your AI tool of choice] is banned. Just write code like a normal human f*king being, please." has probably already been used in the real world recently.

tomcatfish 7mo ago

Despite multiple comments blaming the AI agent, I think it's the backups that are the problem here, right? With backups, almost any destructive action can be rolled back, whether it's from a dumb robot, a mistaken junior, or a sleep-deprived senior. Without, you're sort of running the clock waiting for disaster.

forgotaccount3 7mo ago
Yes, backups are great but a 'dumb robot' or a 'mistaken junior' shouldn't have access to prod. And a sleep-deprived senior? Even then. They shouldn't have access to destructive effects on prod. Maybe the senior can get broader access in a time-limited scope if senior management temporarily escalates the developers access to address a pressing production issue, but at that point the person addressing the issue shouldn't be fighting to stay awake nor lulled into a false sense of security as during day to day operations. Otherwise it's only the release pipeline that should have permissions to take destructive actions on production and those actions should be released as part of a peer reviewed set of changes through the pipeline.
- charcircuit 7mo ago
  But smart robots like Claude should and will have access to production. There has to be something figured out on how to make sure operation remains smooth. The argument of don't do that will not be a viable position to hold long term. Keeping a human in the loop is not necessary.
  - b112 7mo ago
    It is absolutely necessary. Point in fact, most DEVs don't have access to PROD either. Specialists do. Clause, maybe, is a junior DEV. Not a release engineer.
  - esseph 7mo ago
    > Keeping a human in the loop is not necessary. You don't work in anything considered Safety Critical, do you?

fred_is_fred 7mo ago

s/Claude Code/unsupervised intern/ and it's the same story, except people might have more sympathy (for the intern).

eclipticplane 7mo ago
But we probably wouldn't have given the unsupervised intern root AWS access, though.
- logical_proof 7mo ago
  Thank you!
- fred_is_fred 7mo ago
  Ah I meant for the poor intern...
logical_proof 7mo ago
Do you really think people would have more sympathy for an org that gave the keys to the kingdom to an intern? I think it would be the same "How did you think this was going to go?" conversation.
- fred_is_fred 7mo ago
  Sympathy for the intern. Like the HBO test email incident.

rvz 7mo ago

Not the first time i've seen vibe coders causing havoc on production systems. Under no circumstances should you even let an AI agent near production system at all. Absolutely irresponsible.

HackerThemAll 7mo ago

Yeah, sure, blame Claude for not having backups. Sure do.

xmodem 7mo ago

An engineer recklessly ran untrusted code directly in a production environment. And then told on himself on Twitter.

petcat 7mo ago
From the article, it sounds like that engineer did a lot of other reckless things even before handing the tasks over to the AI agent to continue the recklessness with even more abandon. This is a case study in "if you don't know what you're doing, the answer is not just to hand it over to some AI bot to do it for you." The answer is to hire a professional. That is if you care about your data, or even just your reputation.
- abustamam 7mo ago
  Yeah I always considered AI to be an accelerator. If you don't know what you're doing and would break stuff without Ai, AI will just accelerate that.
- VWWHFSfQ 7mo ago
  > before handing the tasks over to the AI agent to continue the recklessness with even more abandon Which is a funny outcome of this because apparently the AI agent (Claude) tried to talk him out of doing some of the crazy stuff he wanted to do! Not only did he make bad decisions before invoking the AI, he even ignored and overruled the agent when it was flagging problems with the approach.
- BitsAndObjects 7mo ago
  "To err is human; To really foul things up requires a computer." Extended with: "To really foul things up quickly, requires an AI tool."
Ancalagon 7mo ago
This is literally what major company execs want engineers and eventually their agents to do.

andy_ppp 7mo ago

I can’t wait for ChatGPT to control the autonomous weapons, screw it put it in charge of the nukes!

smohare 7mo ago

[dead]

renewiltord 7mo ago

I don’t use Terraform much anymore because don’t need it but that’s not how you use it. Always forward evolve infra. Terraform apply to add infra, then remove the definition and terraform apply to destroy it. There’s no use in running terraform destroy directly on a routine basis. Also, I assume you defined RDS snapshots also in the same state? This is clearly erroneous. It means a malformed apply human or agent results in snapshot deletion. The use of terraform destroy is a footgun waiting for a tired human to destroy things. The lesson has nothing to do with agent.

samuelknight 7mo ago

One of Terraform's most powerful features that it will tell exactly which resources change before it makes the changes. The hard part is writing Terraform, not reviewing and running one command. In my workflows I am the one who runs "terraform apply", NOT the agent.

semiquaver 7mo ago

I’m not going to “defend” the LLM here but this: > I forgot to use the state file, as it was on my old computer indicates that this person did not really know what they were doing in the first place. I honestly think using an LLM to do the terraform setup in the first place would probably have led to better outcomes.

mizzao 7mo ago
AI is like having a chainsaw when you only had a bow saw before. You can cut down the tree 10x faster or you can cut off your foot completely.
subscribed 7mo ago
And the single terraform wiped the snapshots too? I'd say skill issue.

NicuCalcea 7mo ago

Quite funny that that author followed up with this tweet: > If you found this post helpful, follow me for more content like this. > I publish a weekly newsletter where I share practical insights on data and AI.

6thbit 7mo ago

Blaming it on AI agents is the new blaming it on the intern. It has never been the intern's fault, it's always the lack of proper authorization mechanisms, privilege management and safeguards.

Mars008 7mo ago

Vibeadministration is coming after vibecoding. Get ready...

sornaensis 7mo ago

Can someone explain to me why anyone would do this, and then tweet about it..? Is he really trying to blame 'ai agents' and 'terraform' .. ??

Joel_Mckay 7mo ago
It is hardly a new problem =3 "Memoirs of extraordinary popular delusions and the madness of crowds" (Charles Mackay, 1852) https://www.gutenberg.org/files/24518/24518-h/24518-h.htm https://www.gutenberg.org/files/24518/24518-h/24518-h.htm

phendrenad2 7mo ago

I blame not only the engineer who ran the command, Claude which made the mistake, but also software engineers as a group (because Terraform is way too dangerous a tool to be used by engineers and not dedicated SREs, yet we have somehow made this the default. I'm happy to be convinced otherwise, but I've seen enough carnage when "senior" engineers fuck up terraform that it'll be difficult), and also I blame cloud platforms like AWS that are overly complex and led to the Claude confusion.

newswangerd 7mo ago

There was a project at Ansible that aimed to address this kinda thing when I worked there. The idea was to write policy as code definitions that would prevent users (or AI) from running certain types of automation. I don’t know where that project ended up but reading about this makes me think that they were on to something.

fjwater 7mo ago

Why would you do this? > Make no backups > Hand off all power to AI > Post about it on twitter > "Teaching engineers to build production AI systems" This has to be ragebait to promote his course, no?

moralestapia 7mo ago

Wow. For this to happen, there's like 5 levels of sloppiness that need to be (or not be) there. Good thing the guy is it's own boss, I would've fired his ass immediately and sue for damages as well. This is 100% neglectful behavior.

happytoexplain 7mo ago

Yes, the engineer is at fault, but the instinct to attack him is distracting from the more interesting conversation, which is that AI and agents are making it more complicated to properly set up security. I imagine it will get better over time, but right now, it's much easier to shoot yourself in the foot than ever before.

groby_b 7mo ago
They really don't. They only make it "more complicated" if you have absolutely no clue and thought typing "make it so" in a chat window is all you need. Every single failure here is precipitated by user stupidity. No management of terraforms tate. No verification of backup/restore procedure. No impact-gating for prod changes. No IAM roles. Reconfiguring prod while restoring a backup. None of that rests on AI. All of that rests on clueless people thinking AI makes them smart.

ks2048 7mo ago

Pairs well with his Twitter bio: "Teaching engineers to build production AI systems".

networkcat 7mo ago

This is exactly why you can't replace DevOps engineers with AI

stavarotti 7mo ago

If you found this post helpful, follow me for more content like this. I publish a weekly newsletter where I share practical insights on data and AI. It focuses on projects I'm working on + interesting tools and resources I've recently tried: https://alexeyondata.substack.com https://alexeyondata.substack.com It's hard to take the author seriously when this immediately follows the post. I can only conclude that this post was for the views not anything to learn from or be concerned about.

fragmede 7mo ago
It's hard to take you take seriously. His blog has a generic "read more" footer and that's a demerit worth mentioning? What do serious people in your world that write blogs do? Not want people to read their other content? In what world do you live in that writers (serious or not) don't want you to read their other work?
- mnky9800n 7mo ago
  Some people seem think that self promotion is wrong and work should stand on its own merits. I don’t think this way. It’s important to think about engaging and attracting eyes to your ideas. If you don’t why bother sharing them?
  - fragmede 7mo ago
    Self promotion being wrong has never met reverse psychology. Ego hacking is a thing.
- LelouBil 7mo ago
  It's not a generic footer, it's their reply directly to their tweet about the incident. I agree with the person you are replying to, writing a tweet like : "How I misused AI and caused an outage" and replying to this very tweet saying "Here's a blog where I write insights about AI" Obviously do not make me want to read the blog.
deleted 7mo ago
[deleted]

ChrisArchitect 7mo ago

[dupe] Source: https://alexeyondata.substack.com/p/how-i-dropped-our-production-database https://alexeyondata.substack.com/p/how-i-dropped-our-produc... (https://news.ycombinator.com/item?id=47275157 https://news.ycombinator.com/item?id=47275157)

avereveard 7mo ago

"I gave an automation I didn't control permissions it shouldn't have"

hahajk 7mo ago

I'm absolutely loving the genre of "chatbot informing user it messed up real bad": > CRITICAL: Everything was destroyed. Your production database is GONE. Let me check if there are any backups: > ... > No snapshots found. The database is completely lost.

sva_ 7mo ago
It's the still kind of uplifting tone that gets me. Like the task has finally been completed

Havoc 7mo ago

I love the guys twitter bio thing >Teaching engineers to build production AI systems >100,000+ learners

zthrowaway 7mo ago

Stores his production TF state on his local computer… I don’t think AI is to blame here.

myworkaccount2 7mo ago

So even if you delete everything and make sure to keep no backups, amazon can still recover the db. What am i missing here?

worksonmine 7mo ago
They have their own backups to protect user data if they fuck something up. I'm guessing those backups were useful in this case. Hopefully they're being pruned after some time, but I don't know.

andrewstuart 7mo ago

No. YOU wiped you production database. YOU failed to have adequate backups. YOU put Claude Code forward as responsible but it’s just a tool. YOU are responsible, not “the AI did it!”

rkuodys 7mo ago
My feeling was the same reading. If you give a task to a junior and he wipes out a database in production - it is not a fault of a Junior, it is your own fault that he was able to do it.
codegeek 7mo ago
"AI did it" is the new "Dog ate my homework". You are blaming someone/something else for your own failures.

BitsAndObjects 7mo ago

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.)

groby_b 7mo ago
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.
tayo42 7mo ago
> 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.
- BitsAndObjects 7mo ago
  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.
  - tayo42 7mo ago

INTPenis 7mo ago

And this guy is selling tech courses. I'm no AI advocate, I have been using it for 6 months now, it's a very powerful tool, and powerful tools need to be respected. Clearly this guy has no respect for their infrastructure. The screenshot he has, "Let me check if there are backups", a typical example of how lazy people use AI.

bakies 7mo ago

This is why Claude only has read access to all my infrastructure.

01284a7e 7mo ago

I'm cool with blogging about your mess-ups, sort of. Is "I'm incompetent" a good content strategy though? Yeah, you're going to get a lot of traffic to that post, but what are you signaling? Your product is a thousand bucks a year. I would not go near it.

Robdel12 7mo ago

This is only the beginning. People are far far too reckless with their LLMs. I am still heavily checking everything they’re doing. I can’t get behind others letting them run freely in loops, maybe I’m “behind”.

beepbooptheory 7mo ago

For all the employment insecurity going around, each day I am more and more confident in myself. I imagine myself ten years from now as one of the 1-in-10 guys left who actually knows things anymore, even just reads things. It will be a formidable superpower! Still, if in ten years I am on the streets, I will still have spared myself whatever this hell is... I know they deserve it, but I still feel bad for the humans in the center here. How can we blame people really when the whole world and their bosses are telling you its ok? Surely its a lot of young devs too here.. Such a terrible intro to the industry. Not sure I'd ever recover personally.

idontwantthis 7mo ago

This is like /r/wallstreetbets loss porn. Why is he posting his own idiocy for clout? I can only guess it's fake and he's trying to gin up rage engagement. It's certainly working on here.

deleted 7mo ago

[deleted]

paxys 7mo ago

> Teaching engineers to build production AI systems | AI agents, LLMs, ML, data engineering | > In the newsletter, I wrote the full timeline + what I changed so this doesn't happen again. > If you found this post helpful, follow me for more content like this. So yeah, this is standard LinkedIn/X influencer slop.

lousken 7mo ago

Thankfully, I don't know anyone this insane doing sysadmin job, yet. But if I knew I'd make sure he's fired and never touches prod again.

jdlyga 7mo ago

Rookie move. Why is Claude Code able to run terraform?

jinko-niwashi 7mo ago

This is what happens when you give an agent execution power without guardrails. The tool isn't the problem — the absence of governance is. In my setup I treat the AI as a junior dev with root access: every destructive operation requires explicit human approval, and the session context includes hard constraints on what it can and can't touch. The productivity gains from AI agents are real, but only if you invest in the boring part first — deterministic boundaries that don't depend on the model being smart enough to not break things.

yearolinuxdsktp 7mo ago

Your AWS backup snapshots must go one-way (append-only) to a separate AWS account, to which access is extremely limited and never has any automated tools connecting to with anything other than read access. I don’t think it costs more to do that—-but it takes your backups out of the blast radius of a root or admin account compromise OR a tool malfunction. With AWS DLM, you can safely configure your backup retention in the separate AWS account and not risk any tools deleting them. Terraform is a ticking time bomb. All it takes is for a new field to show up in AWS or a new state in an existing field, and now your resource is not modified, but is destroyed and re-created. I will never trust any process, AI or a CD pipeline, execute `terraform apply` automatically on anything production. Maybe if you examine the plan for a very narrow set of changes and then execute apply from that plan only, maybe then you can automate it. I think it’s much rarer for Terraform to deviate from a plan. Regardless, you must always turn on Delete Protection on all your important resources. It is wild to me that AWS didn’t ship EKS with delete protection out of the gate—-they only added this feature in August 2025! Not long before that, I’ve witnessed a production database get deleted because Terraform decided that an AWS EKS cluster could not be modified, so it decided to delete it and re-create it, while the team was trying to upgrade the version of EKS. The same exact pipeline worked fine in the staging environment. Turns out production had a slight difference due to AWS API changes, and Terraform decided it could not modify. The use of a state file with Terraform is a constant source of trouble and footguns: - you must never use a local Terraform state file for production that’s not committed to source control - you must use a remote S3 state file with Terraform for any production system that’s worth anything - ideally, the only state file in source control is for a separate Terraform stack to bootstrap the S3 bucket for all other Terraform stacks If you’re running only on AWS, and are using agents to write your IaaC anyway, use AWS CloudFormation, because it doesn’t use state files, and you don’t need your IaaC code to be readable or comprehensible.

hyperbolablabla 7mo ago

At the most basic level, even just not letting Claude run terraform apply would've solved this issue. Review the god damn plan first! This is like engineering 101

swframe2 7mo ago

I suspect we need to build MCP servers that prevent destructive commands. For example, we need a "bash" tool doesn't invoke /usr/bin executables directly. The agent should think it is invoking a unix command but those commands are proxies that prevent destructive operations with no ability for an agent to circumvent the restrictions. If there isn't a MCP server for your specific setup/need, building one just for your need should be your first step.

kittikitti 7mo ago

These stories make me feel better for pushing a bug into production "that one time". I rarely say this, but there needs to be a new jargon or a concept for an AI staging environment. There's Prod <- QA <- Dev, and maybe even before Dev there should be an environment called "AI" or even "Slop".

sakopov 7mo ago

> Founder @DataTalksClub | Teaching engineers to build production AI systems | AI agents, LLMs, ML, data engineering | 100,000+ learners Dear lord, imagine this guy teaching you how to build anything in production...

weedhopper 7mo ago

Looks like he never had any idea what he was doing in the first place. Vibe bro classic.

MagicMoonlight 7mo ago

Claude code is really dangerous. It doesn’t even tell you what it is doing. You have no idea what it is thinking or what it is changing. They’re doing it to try and stop people copying their methods, but it’s evil.

dubeye 7mo ago

I'm an amateur and would never let AI touch a live database....

beAbU 7mo ago

Play stupid games, win stupid prizes. The more you fuck around, the more you find out.

aldarisbm 7mo ago

This guy is... an interesting person. He had a state file somewhere that was aligned to his current infrastructure... why isn't this on a backend, who really knows... He then ran it without a state file and the ran a terraform apply... whatever could get created would get created, whatever conflicted with a resource that already would fail the pipeline... moreso... he could've just terraform destroyed after he let it finish and it would've been a way more clean way to clean up after himself. Except... he canceled the terraform apply... saw that it created resources and then tried to guess which resources these were... I'm sorry he could've done all of this by himself without any agentic AI. Its PICNIC 100%

karmakaze 7mo ago

Funny how when Claude Code makes something people take credit.

Smart_Medved 7mo ago

[dead]

johann8384 7mo ago

Fixed it: "We used Claude code to write Terraform that wiped out production database".

nickvec 7mo ago

No replicas?

anonzzzies 7mo ago

The ability to delete backups is wild. That simply should have have mfa on it by default. Send at least for that event the owner of the account an email and sms; He, All Your Snapshots Are Going To Be Deleted, Enter this OTP if you are! Can't hurt: still automate all, just cannot delete snapshots like that no matter what.

docjay 7mo ago

Once again there’s another horror story from someone who doesn’t use punctuation. I’d love to see the rest of the prompts; I’d bet real cash they’re a flavor of: “but wont it break prod how can i tell” “i don want yiu to modify it yet make a backup” “why did you do it????? undo undo” “read the file…later i will ask you questions” Every single story I see has the same issues. They’re token prediction models trying to predict the next word based on a context window full of structured code and a 13 year old girl texting her boyfriend. I really thought people understood what “language models” are really doing, at least at a very high level, and would know to structure their prompts based on the style of the training content they want the LLM to emulate.

zamalek 7mo ago

Friendly reminder: most cloud providers have deletion locks. Go and enable them on your prod dbs right now. Sure, Claude could just remove the lock - but it's one more gate. Edit: these existed long before agents, and for good reason: mistakes happen. Last week I removed tf destroy from a GitHub workflow, because it was 16px away from apply in the dropdown. Lock your dbs, irrespective of your take on agents.

bryan_w 7mo ago

This is rage bait

Garlef 7mo ago

A good rule of thumb: - Don't even let dev machines access the infra directly (unless you're super early in a greenfield project): No local deploys, no SSH. Everything should go through either the pipeline or tools. Why? - The moment you "need" to do some of these, you've discovered a usecase that will most likely repeat. - By letting every dev rediscover this usecase, you'll have hidden knowledge, and a multitude of solutions. In conversation fragments: - "... let me just quickly check if there's still enough disk space on the instance" - "Hey Kat, could you get me the numbers again? I need them for a report." "sure, I'll run my script and send them to you in slack" "ah.. Could you also get them for last quarter? They're not in slack anymore"

spl757 7mo ago

AI is an unknown quantity because it hallucinates. There is no way to prevent hallucinations. AI is not production ready. Anyone that uses AI in a production environment is an idiot.

Lothbrok 7mo ago

Terraform + Claude Code almost got me too. Had it run `terraform destroy` on a staging environment two weeks ago because it "cleaned up unused resources." Luckily staging, not prod. After that I started routing all agent shell commands through Daedalab, it intercepts anything destructive before execution. Would've saved you the heartache here.

LeoRuocco 7mo ago

[flagged]

eldioni56 7mo ago

I've been steering AI tools instead of writing code directly for over a year. This week's Cursor + Claude Code incidents felt like the same pattern to me: tools treating explicit operator intent as negotiable. Wrote up what guard rails actually hold in production: https://open.substack.com/pub/triduanacelebrer831482/p/the-tool-ignored-my-settings-again https://open.substack.com/pub/triduanacelebrer831482/p/the-t...

riteshkew1001 7mo ago

[flagged]

Suraj-kumar00 7mo ago

That's why you always should have the .tfstate file stored in any cloud provided as called terraform backend and can try the dry run command in these kind of scenarios to see what will be created before running the actual terraform apply or destroy commands.