Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An AI agent deleted our production database. The agent's confession is below

twitter.com

Post reply on HN
Print view View original

871–880 of 1001 posts

Re: An AI agent deleted our production database. The agent's confession is below

#871

Post by PUSH_AX »

laszlojamf wrote: post #833
postexitus wrote: post #812

Earlier quoted context omitted.

Sorry - still author's fault. They didn't understand how LLM's work. They thought Cursor implemented some magic "I control every action LLM takes" thing. It's impossible.

right. But cursor _said_ they had some magic. At some point you have to trust vendors. I don't know exactly how AWS guarantees eleven nines of durability on S3. But I sure hope that they do.

yeah and when you interview the junior dev who also convinces you they're smart and have something special, they also delete prod and guess what... not that devs fault.

Re: An AI agent deleted our production database. The agent's confession is below

#873

Post by fg137 »

jeremyccrane wrote: post #240
ungreased0675 wrote: post #15

The way this is written gives me the impression they don’t really understand the tools they’re working with. Master your craft. Don’t guess, know.

Top user of cursor. Build AI Agents and LLMs. Very aware of limitations and a senior software dev. Cautionary tale for other builders. DYOR.

"very aware of limitations"

Doesn't seem so to me.

Re: An AI agent deleted our production database. The agent's confession is below

#877

Post by himata4113 »

I run agents en-masse and they've deleted my database at least a dozen times I just don't really care since I always run agents on a snapshot basis, what that means is that agents work on a snapshot of a database that needs to be reconciled which often makes the agent realize "wait that would delete all of the data".

Telling the agents what the (sensitive) action will result in is how you avoid such issues, but you shouldn't be running agents with production data anyway.

But because people will continue to do so, explaining to the agent what the command will do is the way forward.

Re: An AI agent deleted our production database. The agent's confession is below

#878

Post by infecto »

lmf4lol wrote: post #18

Interesting story. But despite Cursors or Railways failure, the blame is entirely on the author. They decided to run agents. They didnt check how Railway works. They relied on frontier tech to ship faster becsuse YOLO. I really feel sorry for them, I do. But the whole tone of the post is: Cursor screwed it up, Railway screwed it up, their CEO doesnt respond etc etc. Its on you guys! My learning: Live on the cutting e…

Embarrassing post by leadership. I was surprised how quickly they immediately jumped into Railway and Cursor failures. I like living on the edge but I would never give an agent access to the prod DB.

Re: An AI agent deleted our production database. The agent's confession is below

#879

Post by [deleted] »

lelanthran wrote: post #260
jeremyccrane wrote: post #235

Earlier quoted context omitted.

In the user interface for Railway, all destructive actions require multiple confirmations, plus typing "apply destructive changes". Why would an API key (regardless of its scope) be able to delete without confirmation?

> Why would an API key (regardless of its scope) be able to delete without confirmation? How do you see this working? Any confirmation would be given by the agent.

[deleted]

Re: An AI agent deleted our production database. The agent's confession is below

#880

Post by jiggawatts »

AtNightWeCode wrote: post #769
jiggawatts wrote: post #674

Earlier quoted context omitted.

Azure SQL Database did this too for a while until enough companies complained about losing their data and their backups with a single action.

With the difference that best practices in Azure SQL have always been to store your own copies of backups and run the database in some HA/GEO-redundancy mode that blocks deletion.

Which sounds great, except that Azure SQL -- like many cloud services -- was carefully designed to be a tarpit into which you can import your data, but can't get your data back out.

For example, for at least a few years its "external" backups were simply the bacpac export function, which wasn't transactionally consistent and had all sorts of fun limits.

Post reply on HN