Database accidents with AI: rule conflicts, worktree collisions, and what actually protects you
A story made the rounds recently: an AI-powered cloud environment wiped a user’s entire database. Who clicked what, what was in the chat, what the sandbox was supposed to prevent — none of it will likely ever be cleanly reconstructed. What stays is the uncomfortable question: How does that even happen — and how do I keep it from happening to me tomorrow?
We work with databases inside an AI loop every day. And over the past few weeks two classes of problems keep standing out — both subtle, both with real data-loss potential, and neither solvable by adding “one more memory line.”
Observation 1: The sandbox blocks more strictly now — and that’s good
Lately we see the model stopping much more often when it’s about to write to a database, asking for explicit permission. No more silent “let me just run that migration real quick”; instead, an audible “may I?”.
That’s progress. This exact class of action — write-side, hard to reverse, often part of “while I’m here, let me also clean this up” — does not belong in autonomous mode. Adding a confirmation loop here catches a large share of the truly expensive accidents before they happen.
But: that doesn’t solve the actual problem. It only takes the edge off it in one spot.
Observation 2: Your own rules sit in each other’s way
This is where it gets interesting. Anyone optimizing for speed has a rule somewhere that says: “For small, trivial things, just do it.” Makes sense — otherwise the model asks before every comma.
The problem: a small database migration feels trivial. Add a column, set an index, rename a field. Three lines of SQL. But it isn’t trivial — it’s potentially data-moving, hard to undo, and expensive in production.
That’s exactly what happened to us. A migration that should have been caught by “DB migrations need approval” was filed by the model under “small trivial things, just do it.” Asked afterward: “Sorry, I classified that as trivial.” The wording of the rule the model invoked — exactly the wording we had written ourselves.
No bad intent, no bug. Two rules with overlapping scope, and the model guessed. Sometimes correctly. This time not.
Rule hygiene is mandatory
If your rules live in multiple places — memory, CLAUDE.md, skill definitions, slash commands, workflow briefings — you have to audit them regularly for consistency. Where do they overlap? Where do they contradict? Which rule wins in a conflict?
Until you actively control this, the model guesses — and sometimes the guess is expensive. A single source of truth for your rules isn’t a luxury, it’s damage control.
This is the same pattern we described in „AI does what it wants — no CLAUDE.md will stop it”: rules are wishes, not guarantees. When two wishes contradict each other, the model decides — and the probability that it decides in favor of the riskier path is not zero.
Observation 3: Worktrees can blow up each other’s DB
This is the story where we actually wiped our own database — and that wasn’t an AI mistake, it was a workflow gap we hadn’t accounted for.
Setup: we work in parallel across multiple Git worktrees. Worktree A creates a migration with a sequential number — let’s say migration 70. Worktree C, created in parallel, also creates a migration — and also takes number 70, because at the moment of creation no 70 existed yet.
Both migrations run, both worktrees think they’re clean. In reality, two different migrations now exist with the same number — and depending on which one runs last, the other is gone, no trace, no warning. And because each worktree has its own local view, the inconsistency goes unnoticed for a long time.
This isn’t an AI problem per se. It would have happened the same way with two human developers working in parallel. But: AI workflows make it more likely, because more parallel tasks across more worktrees produce more migrations in less time than any single human developer ever could.
And the model cannot check at the moment of migration — because it doesn’t see the other worktrees. The single source of truth simply isn’t there.
What protects structurally — and what only feels reassuring
These three points map cleanly onto layers:
- Layer 1: Sandbox confirmation for write operations. Helps against the spontaneous, unannounced “let me just”. Useful, but not yet stable everywhere. Don’t rely on it case by case.
- Layer 2: Consistent rules in one place. Eliminates the cases where the model has to guess between “trivial” and “critical” because both rules apply. Mandatory work, often underestimated.
- Layer 3: A single source of truth for state that lives across worktrees. Migrations, schema versions, running jobs — anything that can’t live inside a single worktree belongs in a shared layer that every instance queries before acting.
Layer 1 is nice-to-have. Layer 2 you have to maintain yourself. Layer 3 is tooling — you either buy it, build it, or skip it. Skipping it just makes it a question of when, not if.
What we’re building at BoostN for this
For exactly Layer 3 we’re currently developing a feature: a shared migrations table as part of the BoostN web app. Instead of every new migration landing only in a local worktree folder, it gets recorded in a collective table — number, description, originating worktree, timestamp. Any AI instance that wants to create a new migration queries that table first. Number 70 already taken? You get a hard answer instead of a shrug.
That solves the worktree problem structurally instead of by discipline. The model no longer has to guess whether its number collides — it knows.
While we’re at it, we’re considering placing the safety net underneath: scheduled database dumps written into the same area. We had this running via GitHub Actions — works, but bumps into storage limits. Inside our own database it’s cleaner, especially for live operations where we want backups anyway — and that’s something we could then offer to clients directly.
Short-term, without tooling
Until tooling like that is broadly available, one cheap discipline goes a long way: before you create a migration in worktree X, manually check the migration folders of every other active worktree. Sounds annoying, takes thirty seconds, catches 90 % of the collisions. In parallel: clean up your rules — one central file, clear hierarchy, no overlap between “trivial just do it” and “critical always ask.”
Conclusion
Database accidents with AI are rarely a single spectacular failure. They’re usually a chain: a slightly too generous speed rule, a slightly too narrow triviality call, a worktree that doesn’t know about the other, a sandbox that didn’t catch this exact action.
The uncomfortable truth: you can’t prompt your way out of this class of accidents. You need layers — sandbox confirmation, consistent rules, shared state. Skip one and eventually you have a story you’d rather not tell. Have all three, and you sleep significantly better — even if the model rolls out one more migration at three in the morning that just “felt kind of trivial.”
Further reading
Zoomed out one step further — the vocabulary from AI safety research, the Replit incident of July 2025, and our anti-cascade rule in detail: „When the AI just says yes — and suddenly the database is gone”.
Entdecke mehr
When the AI just says yes — and suddenly the database is gone
Cascading Failures, Sycophantic Confirmation, Silent Failure: the underrated risk class of AI agents — and how we solve it at boostN.ai.
GlossarSpeech-to-Text (STT)
Speech-to-Text refers to the automatic conversion of spoken language into text by an AI model. In an AI workflow, STT replaces the keyboard as the input channel — what matters is model size and domain vocabulary.
LexikonAI Coding Tools Compared
Cursor, Windsurf, Claude Code, GitHub Copilot, Continue.dev, Aider compared. With table and decision guide for four typical developer workflows.