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 edge? Be prepared to fall off!

For a company that puts DO NOT FUCKING GUESS in their instructions they made a heck of a lot of assumptions

- assume tokens are scoped (despite this apparently not even being an existing feature?)

- assume an LLM didn't have access

- assume an LLM wouldn't do something destructive given the power

- assume backups were stored somewhere else (to anyone reading, if you don't know where they are, you're making the same assumption)

Also you should never give LLMs instructions that rely on metacognition. You can tell them not to guess but they have no internal monologue, they cannot know anything. They also cannot plan to do something destructive so telling then to ask first is pointless. A text completion will only have the information that they are writing something destructive afterwards.

There was practically no responsibility taken by the author, all blame on others. It was kind of shocking to read.

Anyone using these tools should absolutely know these risks and either accept or reject them. If they aren't competent or experienced enough to know the risks, that's on them too.

200% agree. If you decide to use this power you must accept the tiny risk and huge consequences of it going wrong. The article seems like it was written by AI, and quoting the agent's "confession" as some sort of gotcha just demonstrates the author does not really understand how it works...

I don’t know, software systems complicated, it’s pretty much impossible for one person to know every line of code and every system (especially the CEO or CTO). Yeah, it was probably one or two employees set this all up realizing the possibility of bad Cursor and Railway interactions.

if you’re a software dev/engineer, if you haven’t made a mistake like this (maybe not at this scale though), you’ve probably haven’t been given enough responsibility, or are just incredibly lucky.

… although, agreed, they were on the cutting edge, which is more risky and not the best decision.

Yeah the author really should’ve taken some responsibility here. It’s true that the services they used have issues, but there’s plenty of blame to direct to themself

I kept reading and reading to find the part where the author took responsibility for any part of this, then I got to the end.

The whole use of AI agents in this context reminds me of the movie "War Games"

  > A strange game.
  > The only winning move is
  > not to play.

Right! Blaming an agent or anyone else is crazy. The author built a system that had the capability of deleing the prod database.

The system did delete the database cause the author built it like that.

And they decided to leave a token with destructive capabilities in the agents access, and decided to not have verified backups for their database.

My team practices "no blame" retros, that blame the tools and processes, not the individuals.

But the retro and remediations on this are all things the author needs to own, not Railway or Cursor.

- Revoke API tokens with excessive access

- Implement validated backup and restore procedures

- ...

I love boring tech. It's reliable as hell and not as full of hidden surprises. Screw the cutting edge for serious work.

It's hilarious how much they can't take any accountability for running a random text generator in prod, and they could not even be bothered to write their own tweet.

I do not feel sorry, but I do feel some real schadenfreude.

100%

Trying to run a blame game is such a facepalm.