Claude Code deletes developers' production setup, including database(tomshardware.com) |
Claude Code deletes developers' production setup, including database(tomshardware.com) |
His post-mortem is solid but I think he's overcorrecting. If he does this as part of a CICD pipeline and he manually reviews every time, he will pretty quickly get "verification fatigue". The vast majority of cases are fine, so he'll build the habit of automatically approving it. Sure, he'll deeply review the first ones, but over time it becomes less because he'll almost always find nothing. Then he'll pay less attention. This is how humans work.
He could automate the "easy" ones, though. TF plans are parseable, so maybe his time would be better spent only reviewing destructive changes. I've been running autonomous agents on production code for a while and this is the pattern that keeps working: start by reviewing everything, notice you're rubber-stamping most of it, then encode the safe cases so you only see the ones that matter.
That's very different than asking it for help to make a plan.
Claude Code has no agency. It does what you tell it, where you let it, with a randomized temperature where it might randomly deviate.
Its a habituation, as much as a desire to avoid finding people at fault.
Who hasn't accidentally deleted a resource because that property triggers a resource delete/create instead of an update?
It would help if it was obvious what the key fields were. But for some reason docs usually don't tell you.
Sometimes they realize their MCP doesn't have access to something, so they pull an API Token for the service from the env vars of either my dev laptop, or SSH into one of the deployed VM's using keys from ~/.ssh/ and grab the API Token from the cloud VM's and then generate a curl command to do whatever they weren't given access to do.
Simple examples, but I've seen more complex workarounds too.
Sprite.dev from fly.io is another good one that I had heard sometime ago. I am hearing less about it but it should only cost for when the resources are utilized which is a pretty cool concept too.
No. Definitely not. Regards, the CIA and the NSA /s
the fix has always been to limit what can be done directly to prod, and put it through both review, and tests before a change can touch production.
The difference is that if a human does it there usually is done accountability, you’ll be asked how it happened and expected to learn from it. And if you do it again your social score goes down, nobody will trust you and you’ll be consider a liability. If a cli tool does it the outcome is different, you might stop saying the tool or you might blame yourself for not giving the tool enough context. And if it does it again you might just shrug it off with “well of course, it’s just a tool”.
Regardless it is hard to dismiss the fact AI is making it easier for randoms to develop software. And it will keep getting better the more integrated and controlled it gets.
That's nonsense. First, most people haven't deleted the production environment by accident. They have enough sense to recognize that as a dangerous thing and will pause to think about it. Second, the ones who do make that mistake learn and won't make it again, which is not something the clanker is capable of.
Maybe HN leans more toward the hobbiest and student side then it does industry professionals, I don't know, but you don't have to look far to find someone who swears up and down you can run a couple agents in a loop and have it build multi million line code bases with little to no oversight.