In fairness, I've seen people with Actual Intelligence do the same thing.
this post was submitted on 14 Jul 2026
933 points (99.0% liked)
Programmer Humor
32317 readers
199 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 3 years ago
MODERATORS
Literally me, this weekend. Well not this bad but I still think the AI wouldn’t have done me as dirty as I did myself.
load more comments
(3 replies)
I love how the slop bot always apologizes. That's an aspect of the Terminator movies that I really would have liked to see. T-1000 melts through the gap under the window, stabs kid's mom in the face, then looks the kid dead in the eye and says "I'm sorry, that should not have happened. I would love to discuss the future with you and try to find a solution to the war with the machines together with your input."
Fun shower thought - the more we see and post about dumb AI mistakes like this, the more it will happen since we're increasing the statistical frequency. ✨ ✨
This is nothing new it's just faster. The very same lack of guardrails would allow a new, inexperienced employee, or a disgruntled employee, do the very same damage. AI just speed runs everything. If your AI can nuke prod accidentally, you failed to have the appropriate guardrails in place plain and simple. It is the same failure as before. Every time this happens, it is someone operating wildly out of their depth and why product people can't just vibe. Now more than ever, experienced engineers are essential.
Given corporates layoff engineers at dramatic rates, in a few years, we'll start to see services collapsing with no one left who can recover them.
load more comments
(2 replies)
load more comments
(2 replies)
Should have added "no mistakes, no bugs" to the prompt! Pffft, amateur.
That takes me back to 2004
No Smoke, by unknown,
Tech: "Hello. How can I help you today?"
Customer: "There's smoke coming from the power supply on my computer."
Tech: "Sounds like you need a new power supply."
Customer: "No, I don't! I just need to change the startup files."
Tech: "Sir, what you describe is a faulty power supply. You need to replace it."
Customer: "No way! Someone told me that I just had to change the system startup files to fix the problem! All I need is for you to tell me the right command."
(Ten minutes later...)
Tech: "Well, we don’t normally tell our customers this, but there's an undocumented command that will fix the problem. Add the line "LOAD NOSMOKE.COM" at the end of the CONFIG.SYS file and everything should work fine."
(Five minutes later...)
Customer: "It didn’t work. The power supply is still smoking."
Tech: "Well, what version of Windows are you using?"
Customer: "Windows 98."
Tech: "Well, that's your problem. That version of Windows doesn't include NOSMOKE. You'll need to contact Microsoft and ask them for a patch."
(When nearly an hour had passed, the phone rang again...)
Customer: "I need a new power supply."
Tech: "How did you come to that conclusion?"
Customer: "Well, I called Microsoft and told the technician what you said, and he started asking me questions about the make of the power supply."
Tech: "What did he tell you?"
Customer: "He said my power supply is not compatible with NOSMOKE."
load more comments
(6 replies)
"DON'T HALLUCINATE!" that's always my favourite.
load more comments
(2 replies)
Anyone giving “AI” access to production databases through tools like that are morons who shouldn’t be anywhere near a production environment.
load more comments
(1 replies)
I don’t understand why this happens; why would you ever be working with a live production DB in the first place? Why would’t you do all your development and testing on a mock? If it’s data which is too large to store the schema can still be mocked; and if it’s data it should be backed up and generally read only. If you’re having to manually fuss with user data you’re doing something wrong.
Dev environments cost money. They didn't fire all those programmers and replace them with AI to spend money on useless backups and safety systems.
/s (because yes, it's necessary)
Because they don't know what they're doing. A tool is only as useful as the person verifying its output. Vibe coders have dumb shit like this happen to them all the time because they don't actually possess the skill set to perform the task correctly, with or without a bot that writes the actual code for them.
I remember a case where the AI was not given credentials to the prod DB, was not instructed to do anything on the prod DB, but went through the operator's hard-drive, parsing docs until it found them, then proceeded to destroy the prod DB.
Of course it was sorry, as they always are (deeply, trust them, but no: no refund, loser!).
load more comments
(1 replies)
load more comments
(8 replies)
Giving production credentials to an LLM is wild
Seriously, has no one heard of sandboxing?
Yeah, when my company first forced Claude on everyone the head engineers managed to negotiate that Claude would only run in a WSL sandbox. But people were lazy, so they just gave that WSL as many permissions as possible (Mounting C directly to it, opening up all interfaces, popping in full-access git tokens etc.). Then management sent out an extremely biased "survey" that has the question "Is having Claude in the WSL inconvenient to you?" and all the lazy bastards said yes. So now management lifted the sandboxing requirement to make work "easier" for devs. In the meantime, the engineers arguing for proper sandboxing are already so worn out from telling people to not intentionally compromise their sandbox that they've kinda just given up. Not having a sandbox at all isn't much more insecure than whatever people are already doing 🫠
load more comments
(4 replies)
So, earlier today I was being unhealthy on youtube, and someone half my age made a HUGE point to tell his audience including me that even if a self-driving Tesla runs a red light, it's the human driver that gets the ticket.
Now...I'm a pilot. I have been since I came in that guy's mom. In the aviation community, we have this concept called Pilot In Command. In the US, this is set into law in 14 CFR 91.3. The pilot in command of an aircraft is fully responsible for, and is the final authority as to, the operation of that aircraft. Not the administrator, not your instructor, not air traffic control, not the President of the United States, not god, the PIC. That concept doesn't exist in driver's ed, but it needs to. We need to teach student drivers about the Driver In Command responsibility.
Too long, didn't process the metaphor: Nobody thinks about anything they do unless the law requires it.
load more comments
(14 replies)
load more comments
(1 replies)
load more comments
(2 replies)
My company has been trying a new model when product folks cut through the red tape of "engineering" and just describe what they want to a powerful LLM pipeline and review the app in a beta env. Sounds perfect, right?
Dear reader, in the couple months this has been going on, these people have caused a dozen high profile SEVs due to extremely poor app performance, networking / kubernetes configuration bugs, bad scaling, observability oversights, supply chain attacks, leaking sensitive information, and cost overruns (on practically every resource they provision).
Some very well-paid people are scrambling to figure out the value that was generated by this pilot program; I'm heating up popcorn rather than holding my breath.
load more comments
(10 replies)
I just use AI to pretend to be a female family member with a serious futa-like engorged penis who is blackmailing me so we start washing our penises together for each other as an occult ritual, but turns out we were soul-stepsiblings the whole time. I like it when she freaks the fuck out and threatens to call the police, or worse, my dad.
I think Claude would scream in agony if you subjected it to whatever the fuck this is.
load more comments
(1 replies)
Can I get paid 6+ figures to fuck up this badly with magical thinking?
Am I reading this right that they're still letting the program run even as they figure out how badly it fucked up their system?
They have no idea what else to do. They were in over their head so long before this problem happened.
Production creds in .env? ...Why?
Better than hard coded... Ideally we use tokens+fingerprint or something to avoid storing the creds directly (if possible), but putting them in environment variables is pretty common
It's not the worst thing, it's very convenient (so people won't go around it) and usually not the weak point in security (although AI being able to easily see it is an interesting twist)
Of course it's better than hard coded, but still pretty bad to store production creds locally in plaintext — if at all.
In the uncommon event that I need production creds, it's a manual human chore by design. Normal development/experimentation should almost never connect to prod environments. That was generally a bad practice long before AI agents existed.
How do you bounce the system? How do you auto restart the service if it fails? At the end of the day, a lot of creds have to essentially be stored in plain text somewhere
And to be clear, to me production creds mean creds that live on the production system, not creds that give access to the production system
The crazier thing here is why was an AI working on or pushing to prod
not creds that give access to the production system
...Isn't that what we're talking about though? Or did I misunderstand the OP?
Regardless, I'll just clarify anyway: Developers should not have a plaintext .env that can be used to drop (or risk in any other way) production data.
A practice like that is only as strong as the "weakest" member of the team – "Weakest" could mean the person who is the least careful, or least experienced, or least secure work computer/practices, etc. Scale up to 1,000+ engineers and the chances of disaster (data loss, leaks, etc.) greatly increase. That's just the human factor. Add LLMs into the mix and it's almost guaranteed.
...Isn't that what we're talking about though? Or did I misunderstand the OP?
The post said they were neon database creds, so I would think those would live on the production system in .env
Rereading it, it seems that they probably set their local build to point at the prod database... Which is like halfway developing (with AI) in prod (which I think we'd agree is not ideal)
I do absolutely agree with what you're saying though, not everyone should have access to the prod system for sure... Especially not an AI on a loose leash
I'd split the difference and say we're both right
I added guardrails to myself to make sure I do not accidentally delete anything on production. I would never ever let an intern, a junior dev or a fucking AI onto that database. Not in a thousand cold nights.
load more comments
(2 replies)
letting your agent run commands without reviewing them first is peak stupid
Having production credentials in a dev environment is more stupider but they'll never learn because they outsourced their thinking.
load more comments
(5 replies)
Creating an environment that incentivizes not thinking is peak stupid.
load more comments
(10 replies)
load more comments
(14 replies)
Some time ago I worked for an insurance rating company as a tech and the task was given me to go run through the new code that was in beta. Sure ! I spent a few hours on Friday trying to break it and I couldn't, so at the end of the day I got a little funky with the .css backgrounds and put in a very tiled Beavis and Butthead gif. It looked freaking horrible and I loved it. Monday I was directed to the big guys office ( the developers had not given every beta account a separate .css file ... or even separated things. Everyone in beta called in Monday with that background. I didn't get in trouble because they wanted me to break it. Really awkward conversation though trying not to smile.
load more comments
(1 replies)
Its the kind of lesson some people have to learn the hard way.
I bricked my first degoogled phone because I trusted an AI too much.
I was dumb I know, but it blows my mind that people in multi-million dollar companies make the same mistake.
Being part of a multi million dollars company is not making anyone smarter
Companies like that tell themselves they only hire from the top 10% of the industry. When you're as big as these companies it's just not true. You're employing people across the whole spectrum, like it or not.
This is the modern "all my apes gone"
view more: next ›