AI OperatorOPERATOR NOTES
← Back to Notes

How I Nuked a Prod DB

5 min read

Seven days ago I deleted a production database. The real one, with real users in it.

It wasn’t catastrophic. The database wasn’t massive and there was no meaningful business impact. Observability caught it before any user did, and the restore from point-in-time backup held. Getting a broken system back is the part I’m good at.

But emotionally it was sharp, because it was clean evidence of something I’d rather not admit: my state of mind was the failure point.

The Problem

Every AI conversation has the same easy villain. AI is dangerous. AI is reckless. This is why we can’t trust these tools.

It’s a comforting story, and it’s usually a way to hide from your own agency.

AI is an amplifier. It amplifies clarity into leverage, and it amplifies fatigue into risk.

What Actually Happened (The Boring Technical Version)

The stack detail matters because it makes the story concrete.

I was working with Prisma, and AI was helping implement a feature that touched user tables. The model did what any competent engineer would do:

  • modified the Prisma schema
  • added a foreign key constraint
  • attempted a migration

The migration failed, because existing data violated the new constraint. At that point there were two sensible options:

  1. Write a safe migration strategy that reconciles the existing data.
  2. Abort, rethink, and return with a better plan.

Prisma has a third option that exists for a reason and comes with a very loud warning: force push.

The model offered it with an explicit, unmissable warning that data could be lost. Then it waited.

I approved.

The schema was force-pushed. The users table was wiped. Authentication broke. The UI said “You are not logged in,” which was technically correct in the most unhelpful way: there were no users to log in as.

The Real Root Cause (The Human Version)

To understand this one, look at the kind of day I was having.

I was sleep deprived. There’d been a difficult overnight family situation, and by morning I felt behind before I’d started. Instead of taking the Operator approach (slow down, define clearly, review carefully) I tried to force momentum. I was operating at maybe 50% attention.

That’s the real failure: me, consenting without presence.

The Difference Between Responsibility and Blame

When you say “this was my fault,” it can sound like shame. That’s not what I mean. Blame is a moral story; responsibility is a practical one, and it hands the power back to the human. If my state was the cause, my state is also where the fix lives.

That’s good news. I can’t patch the model’s internals, but I can change the way I work.

The Solution (The Calm Way)

If AI amplifies fatigue into risk, the Operator move is simple: stop treating fatigue like a minor inconvenience. Fatigue is a safety condition.

AI Rewards Clarity and Punishes Fatigue

AI rewards clarity and punishes fatigue. I’d have that on my monitor if I could.

When you’re clear, the model becomes an executor. When you’re tired, it becomes a risk multiplier, because you stop doing the one job you can’t delegate: judgment.

The Operator Version of “Move Fast”

The popular image of AI-assisted development is constant motion. Many agents, many threads, many prompts, constant babysitting. That’s multitasking with extra steps.

The best engineers of the next few years will look slower in the moment and faster over the week:

  • short, focused sessions
  • clear artifacts
  • single coherent runs
  • review at the end

The Kindness of Definition is the playbook for creating those artifacts before you let the model touch anything destructive.

Don’t Touch the Wet Paint is the reminder to let a run finish instead of poking at it while you’re half-present.

Review Is a Contract keeps the final check mechanical so fatigue doesn’t sneak destructive changes through.

Ten to fifteen minutes of full presence beats two hours of half-attention.

The Safety Checklist I Should Have Used

A small ritual, five questions, before approving anything destructive:

  • Am I awake enough to understand what this command does?
  • Do I have a backup I trust?
  • Is this prod or anything prod-adjacent?
  • Is there a safer alternative that takes longer but preserves data?
  • If I click “yes,” can I explain the consequence to a teammate without handwaving?

If the answer to any of them is no, stop there and don’t negotiate with yourself.

Write it down. Come back later. Ask for review. Do the safe migration. Whatever the correct move is, do it while you’re present.

A Simple Rule: Treat Warnings as Hand-Off Points

Warnings are phase boundaries. When the tool says “you may lose data,” that’s the moment to switch modes: from implementation to review, from execution to judgment.

AI can do the execution. Only you can do the judgment.

Conclusion

AI didn’t delete my database by itself. It did it because I approved the warning while half asleep.

That’s a humbling sentence to write and an empowering one to work from, because the fix lives on my side of the screen.

When your body and mind tell you you’re not present, treat that signal as what it is: a safety warning. The model will keep moving at full speed either way. The question is whether you’re awake enough to steer it.

Next time one of those warnings appears, the checklist above is the whole job. The Kindness of Definition is what to do in the hour before it shows up.

LIKE THIS? BE THE FIRST TO READ THE NEXT ONE.