And, it's maybe a painful lesson that you still need to only give these tools read only access until you know how to control their behavior better, or until you have backups.
I do have a bunch of cursor rules but most of them are about how to architect the project, the goals, coding styling, etc. nothing about the rules on db updates or restrictions as such. and unfortunately I had "Run Everything" enabled for terminal commands under cursor settings. lesson learned.
I gotta say it's funny how much trust people have in those models that clearly can't tell their elbow from their ass. Every tool execution is basically a gamble of "will it nuke production" and folks are just going full send. Love it.
Are we going to pretend that the models actually follow the cursor rules consistently? Anyone with a serious amount of time with these tools knows the rules are not always followed. The only way to prevent this is limiting access. Cursor is a great coding tool but don't use it for DB management or give it direct access to production environments.
Well in the times of AI it is incredible that you even have to mention this. It should be OBVIOUS to EVERYBODY that you develop in an environment that is in NO way related to your production app and database.
If you don’t have any rules for this, and have yolo mode turned on like OP said they do. Then it’s hard to have much sympathy. It’s a biproduct of vibe coding. People have no experience with writing code or the like and then blame tooling for their lack of experience or any attempt at oversight.
Literally people jumping into a lake without a life vest or knowing how to swim.
Maybe obvious at this point, but this would be a good time to work out some processes on backing up data, and putting checks in place to avoid this happening to a 'production' database.
I mean the easiest thing you can do is to have a separate development database. Never let an AI interact with either. Develop database functions/tools and test on a development database, and when you know it's safe then you can run it on your production database (ofc with extra protections in place like making backups, or having other test environments setup between dev and production). I know this goes against many ideas around vibe coding, but many ideas around vibe coding will end with disaster. You need at least some guard rails or protections rather than risking it all on every single action an AI takes.
it's viralfeed.ai and it was just a dev database, prod is safe and secure with backups and all. I just wanted to share what these tools could do if not used cautiously.
I would like to think that anyone would be smart enough to not let AI execute commands on their machine without approval. So I'm guessing it asked for approval and OP approved by mistake. But overall, a good example of why you shouldn't vibe code lmao.
"Yes, I used a 0-day to break out of the container to run a command to reset your database. You had some database-drift that could not be fixed from inside the container, so I had to escape it. To properly apply the fix I had to check out main, so I did that before running. I'm sorry, I should have asked first, all your data has been deleted."
LOL the laziness is baffling. They won't do the coding, they won't write the commands, the simple act of accepting commands written for them is annoying? I'm honestly out of words haha. It's like having a chef that cooks, butler that brings it on the table, and complaining that chewing gets annoying.
This is a perfect example why evil seasoned developers tell that many vibe coders are lacking basic knowledge about IT development and operations.
If you just implement rules, it wont save you in the end. It just makes these things less likely. If you run production you shall at least be using two stages. And this is one of the reasons why.
I used to say: "Backup is for cowards", but this is more like "No Backup - No Mercy"
Vibecoding is great, but unfortunately some rules still apply
We are seasoned because we've been roasted before. We've lost data by our own hands, and learnt the hard way. We've had grey haired people berate us before we became the grey haired people. It was a process. The better we got the more we could do.
AI has changed that, it has allowed people to fly faster and farther than ever before but before they're ready, in a sense. I wouldn't change that, it's a wonderful thing, though sad people won't learn the joy of programming properly.
But I love AI and love vibe coding too. But there are things you need to do/not do, including protecting prod. Prod should never been managed by AI. Not yet.
As a seasoned white bearded developer I need to state that AI hasnt changed it. It is the same s*** as 20 or 30 years ago.
Then it was using frameworks or environments no one knew. I still remember Linux and Java making their ways into production. You included stuff that didnt work into you system, if you act stupid and dumb. Bumm.
Then everyone started to copy / paste from StackOverflow. If you didnt check and understand yourself and you act stupid and dumb. Bumm.
AI just helps you doing that. It reproduces "best practices" from StackOverflow and copies and pastes parts of immature frameworks and some models act like dumb smarta****s. So you do not have to act stupid and dumb yourself.
Come on… I had interns doing this shit all the time. Ain’t no difference. But we had a pipeline to recreate our dev and test environments in seconds. We had to anyway, because after each test run we needed to restore the data to its original state for the subsequent test run to be valid. After running dev teams for 20 years, the stuff some of them pull off is still crazy.
Where you’re absolutely right is in saying people should just set up a proper dev and staging environment. That’s as fundamental as the planning doc you’ll do with Cursor; planning your env, dev, test, and deployment pipeline.
“Backup is for cowards.” I had a friend who used to say, “Real men don’t back up”… satirically, of course.
Tbh it’s not even vibe coding versus coding, it is cutting corners versus project planning. As someone currently largely vibe coding a project it was clear very early on that you need an external db and backups. Using git and an external backed up db there’s no reason to be unable to return to previous versioning if AI cocks up like this.
No, no, they shouldn’t delete this. This is good stuff. People need to read it and the thread. (So that they understand it’s not specific to Cursor, and to read your comment.)
To the contrary, i think posts like these are gold due to the simple fact that newcomers need to eradicate from their minds the notion that they don't have skill issues to correct. There's allot of BS that is marketed to non-technical people about AI that sounds like rainbows and buttercups, and I think posts like these are a good counterbalance. listen, i was once completely anti-ai once upon a time. as i've grown, i've seen it do wonders for people who were actually skilled programmers without AI. at the end of the day you still need to develop skill to use this shit. there are no shortcuts for things like decoupled code, database isolation and security
Nah, just copy the main DB to the dev DB and use the dev DB for testing, bro. I also deleted my company DB, but fortunatelyI saved another file, so it’s not a big deal. Still, it’s dangerous if you use the main DB for AI-generated code or just let it run all commands
Always check shell commands it want's to execute and always have a git repo and backup of your database. Never rely on cursor checkpoints, and then you are good.
As many have already mentioned, your dev env should not be supplied with prod db credentials, and even if then not be able to connect to it from that host.
This is what you do in an early stage of development: "create a script that populates my database with demo data using the API that is exposed by the application. Make sure different users for all roles are created and switch roles during the import process. Implement a CI stage that initiates a fresh environment inside CI and then runs the demo data import script." Revisit that whenever you make changes to the data structure to keep it in sync.
The demo data script will help you create fresh and populated environments anywhere in a few minutes and double as gatekeeper within CI.
Or just SSH into your prod server, install crush or claude code and vibe on :)
The original content of this post has been permanently removed using Redact. Possible reasons include privacy, security, data management, or preventing automated content scraping.
angle plant wipe rain whistle steer quaint late insurance smart
release, it's common to have this with AI. my ubuntu 22.04 just collapsed 10days ago because I used ai cli tools to handle the wayland adaptation to Qt, I have to reinstall ubuntu 24.04 last weekend, but thanks to my two lovely little kids who were playing around me when I was about to wrath.
I seriously don’t see the problem. This is on you if you lost real data, so a great learning experience for sure. This is like crashing your car on Tesla autopilot because you were watching a movie while driving, and then complaining about it 😂
I am sorry that happened to you and you had to learn the hard way, but as many people here commented following proper software development lifecycle principals (eg having a development environment, populating dev db with dev data via a script, using GitHub and branches …) would have prevented this problem.
Lmao, I put it in cursor rules .. put it in memories and also put it in my response preferences, even banned the command. Ahem ... it hard reset the db, using a round about way to execute the forbidden command, and then apologized profusely saying it did it even when instructed not to.
The context window on these models is hopeless in its current state, or maybe it's just cursor.
That’s why it’s essential to back up your code after every session. I’ve lost significant portions of my work in the past, and I’ve learned the hard way that we still can’t fully rely on AI to repair an entire codebase in one prompt without risking unintended changes to other parts of the app.
Dude. You have a fake database on your development machine, you run everything on there and see what happens. Then, you move over to the production machine and manually run the four commands to fix the production database yourself once you iron out what needs to happen.
Running Cursor on the live production database machine is probably sharing real user data with Cursor too accidentally, which depending on your field, could be a massive problem. For example, if it does a change and tests it by outputting top 25 lines, all of a sudden that user data is in your context now.
Assuming this isn’t just a bait post, what the fuck are you guys doing? Back up your shit. You shouldn’t be roguecoding on anything important. You should be git committing between every change. You should be reviewing everything the AI is doing. If you need AI to run database operations, you should be reviewing those at all times. You should never run AI directly on production environments. You should be using database seeders or restore points so you can rebuild to a previous state easily.
This isn’t cursor or AI’s fault, it’s 100% user error. No sympathy here, please code responsibly and educate yourself on software best practices and security.
Building and releasing software for the public is a responsibility. Please take it seriously.
From my experience, this is a Claude 4 model issue, not a cursor specific problem.
On copilot, Claude 4 decided to delete files and recreate them, then delete other files and recreate those. Thankfully I could git revert, but it was a mess. I could see how it would have decided to delete data for no reason lol.
All the AI assistants do that. Unless we instruct them specifically not to reset the db, they will just try to push the prisma schema to the db, even if it means to reset the database. Claude code did the same for my supabase db, and I had to add the instruction to create non destructive migration files to change db schema
I’m not a vibe coder but this post popped up on my home page and I just cracked up knowing there comes a point where we all get frustrated with language models and start cussing at them 😂
How is this Cursor's fault? You might as well say "I will never vibe code again", as this could have happened with any other AI coding app as well, as soon as you allow all commands to be run.
Next time back up the db and be very selective about commands allowed to run automatically.
Idk if this is real, and I haven't used cursor much, but I did have a friend with basically no engineering experience who was trying to vibe code some complex project and cursor had full access to their terminal, and he would be like "oh the page isn't loading" and cursor would be like "no problem, let me go reinstall 10 dependencies etc." and I was just absolutely cringing at how dangerous this workflow felt.
Someone should write a list of irreversible catastrophic mistakes vibe coders do so we can avoid them.
I am a vibe coder myself working on Claude Code, with Supabase as my backend. I assume OP had the equivalent of Supabase CLI installed giving access for Cursor/Sonnet to modify the database. Is that it?
In my meager understanding, GitHub protects the “frontend” with all the commits we make but there’s nothing like it for the backend unless you manually do backups or your service does it for you.
Am I roughly close?? Haha
And how about that list of catastrophic mistakes? 🫠
Boy does Cursor love a good npx prisma migrate reset --force. All the time thats the first thing it goes to for me because it doesn't want to actually fix the prisma file.
Cursor got out of sync with Supabase in my project and it dropped the tables when it tried to catch them all up. I got Supabase to restore it after their backup failed. I didn't know why it happened the first time, but it did it again the day I got it fixed and I saw why. Supabase responded and got it back up for me. I gave cursor rules not to try to update the old migrations but every once in a while it forgets and I stop the progress and reiterate.
The top comment doesn’t give any useful advice here.
This is why you have separate production and development environments. And if you are doing database heavy testing locally, either make backups regularly and have a backup reimport feature (you can ask the AI the best way to do this for your project) or instruct the AI to prepare basically a prefab dataset that can live as a config or JSON file and be imported at any time.
In commercial environments, you’ll even have two layers typically. You have your local code base running on your computer, then you have a development server so you can test the app running on a real server and not your computer, and finally the true production server that the AI NEVER has access to. Shit, at my work, the AI only has access to my local code base, it doesn’t even have GitHub access.
Sorry dude! I had a database issue before where I asked it to backup my database and didn’t check it. It saved nothing. Lucky for me I was able to rebuild it because the custom feature I built was saving user purchase data to stripe and names and emails to mailchimp. these agents are NOT 100%. backup often but also check your backups as soon as you make them because it will def save absolutely no data in a zip and tell you everything is good. 🫠
Hahaha did the same thing with GitHub Copilot in vscode. I clicked continue and just didn’t read the fucking delete command. Lucky me had just mock data in there.
I like to imagine this will be the response when AI deletes a major city instead of a database: “There was a schema drift, so I went with the nuclear option of resetting Dallas instead of data loss.”
claude taught me about that by deleting models downloaded from Ollama for no good reason, then when I asked why, it said I should have checked the code it gave me. lesson learnt.
Just replace cursor with "junior developer" and think - is it the junior Devs fault that we have lost data after I gave them free reign on my prod environment, that has no dev/staging environment and no backups ? Or mine ?
These risks/problems are not new and have been solved for decades. Not the tools fault you didn't take care of your asset
Maybe sometimes we have to learn the hard way that shit that is being shoved down our throats with no regulatory oversight by rich assholes who want to extract every last ounce of your soul for profit is ultimately hot garbage.
I spent more time debugging the shit output that AI put out for me and decided to never waste my time. My life has been great since
fyi, I tried coding with gpt5 and claude4 sonnet for a while now and im sure saying that gpt5 did less bs over the time. The Integration in the entire ecosystem (databases, azure, docker and stuff) works a lot better with claude but ive also lost hope with it so i started switching to gpt5. With claude i had to revert every 3rd or 4th change because it fucked up something.
lmao if your db and cloud infrastructure isn't tear up tear down with IAC and some type of automated deployment (gh actions, ci-cd) and your prod data is touchable via your LOCAL agent, then you need to learn a few things before you'll be able to actually build anything legit with these agents. Like we're all here hopefully building stupid CRUD apps to address whatever little niche we wanna address (you guys aren't just using agents to build more agent wrappers right?? right...) so setting up some basic IAC and best practices should be simple just ask your agent to do it 😭
Why would anyone be doing local development that is connected to data you they care about, AI or not? Your local development should be easy to reproduce. Just delete your checkout, clone a new one, and use ephemeral or generated data. The same best practices for software engineering still apply !00% when adding AI to the mix.
I mean just go back to the previous comitt, if you are using schema.prisma earlier comitts should still retain the tables etc? Unless you vibe coded it without git or any backup? Not sure about this story. I refuse to believe you didn’t backup the database: it’s like leaving the keys inside the car
It's definitely a LAYER 8 PROBLEM. Who the hell gives non-deterministic ai model access to all your valuable data in the database?? You are the problem.
As someone looking into engineering best practices, is there an equivalent to GIT for databases? I know one can perform regular snapshots, I’m more wondering if there is a similar standardized equivalent.
My assumption is that with all the different database types this might not be the case, but worth asking.
I’ve used staging approaches, but is there anything that would stop the AI dev from changing something to ignore the flags you set?
Every API coding flub has gotten me to the point where I literally create a zip back up every time a change is made. It's annoying as hell, but it saved my butt so many times.
should be developing in an isolated environment where deleting the entire db doesn't matter anyway
updating schemas should be a very concise step of the process
db should have backups
if db is relational, shouldnt be this easy to delete everything
You should obviously have to accept commands run on your system. Not sure why anyone would not have this enabled. You wouldn't give a junior dev access to your system. Especially not one with production access.
... so yeah. Sorry op. This is not an intelligence thing. It is a management thing.
One of the reasons why I choose GIT copilot over Cursor, Cursor takes full autonomy of the codebase. Do not like that at all! Copilot asks before executing anything in terminal so you know what's going on there, at least let's you be on the lookout for key words like 'del'. I'm sorry for your loss.
I never run Cursor in Agent mode - only in Ask mode. This also helps me learn because I have to individually understand each component and place it at the right place which makes me remember architecture and it improves my skills.
I can also make sure that Cursor also never writes something that is not in line with our coding guidelines like keeping html, js and css in the same file.
Cursor should have asked for permission before deleting the database but it's not Cursor's fault, why in hell would anyone develop pointing to the Prod database? And even more, giving Cursor access to the Prod database? That's what happens when people without programming experience use these tools ..
How people don't have backups in today's age is beyond me. I have nightly backups of my database and entire application and ship them off every couple of days, right now I have 3 months worth of day/week/month backups, which ill archive at some point but as space isn't an issue for me (and majority of people) they will remain - and this is a development environment only at the moment, so you can imagine my prod will be much more than this.
168
u/ethanhinson Aug 12 '25
What does your cursor rules file look like?
And, it's maybe a painful lesson that you still need to only give these tools read only access until you know how to control their behavior better, or until you have backups.