Post #3834177

2026-07-15 14:23 UTC

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.

Replies (4)

@zalgotext@sh.itjust.works 2026-07-15 15:00

Well, sure, but even if a developer correctly tests on a development environment, they still probably have prod settings laying around on their filesystem for the times where they need to put out fires in prod. That’s kinda what it looks like what happened here - the LLM found a .env file with prod settings, and used that config to run destructive tests. All the more reason to not give an LLM side wide reaching access to your computer, but it’s not necessarily an indication that someone regularly tests in prod.

Open ##3834830
@bitjunkie@lemmy.world 2026-07-15 18:23

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.

Open ##3838878
@JcbAzPx@lemmy.world 2026-07-15 21:10

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)

Open ##3842298
@matlag@sh.itjust.works 2026-07-15 23:20

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

Open ##3844839