Git Has Undo. Your Database Doesn't.
Rollback works for code, not for customer data. Why the real risk in AI-accelerated development moved to irreversible operations, and what to demand in a contract
I've been handed the keys to more than one production database that nobody at the company could explain.
The pattern repeats. A funded founder hires fast builders, gets a working product in weeks, and is genuinely happy about it. Six months later there are three tables that look like they hold customer records, two are stale, nobody knows which two, and the person who ran the migration that split them left in March and doesn't answer email.
That's the engagement I get called into. Not "our code is bad." Our data is a mystery and we're about to raise.
So when I saw that someone shipped diffium-db, a terminal tool that shows you live what an agent or a migration is changing inside your database, my first reaction wasn't about the tool. It was about what has to be true for that tool to be worth building. Somebody looked at how software gets made in 2026 and concluded that we now need a rearview mirror pointed at the database, because things are happening in there faster than a human can narrate them.
That's the tell. Read it as one.
"We can always roll it back" is a statement about code
Founders have absorbed a comforting idea from the last two years: AI writes the code, and if the code is wrong, you revert it. Ship Tuesday, revert Wednesday, lose a day.
That's true. Git is a time machine for text files, and it works beautifully.
Your database is not a text file. A migration is just a script that changes the shape of your data, and once it runs, reverting the script does not un-run it. If it merged two columns into one, normalized every phone number, deduplicated accounts by email address, or deleted rows it considered orphaned, the previous values are gone. Not "hard to get back." Gone, unless someone kept a copy and someone else has actually practiced putting that copy back.
There's a small set of operations in any company that behave this way. Schema changes. Bulk updates and deletes. Backfills. Anything touching payments or authentication. And anything that writes to the outside world: the email you sent to your entire user list, the charge you put through Stripe, the webhook you fired at a customer's system. You can refund a charge. You cannot unsend the receipt.
Everything else in your product is reversible and therefore cheap to get wrong. This handful of operations is where the company-ending mistakes live, and it's maybe two percent of the work.
What 10M monthly users taught me about that two percent
At my last company, a bad migration was not an engineering incident. It was a company-level event, the kind where the CEO finds out before the fix is written.
When we grew from 4 engineers to 31, I did not add process everywhere. Most of the time I'd rather a good engineer ship without asking me. What I did add was a gate on exactly the irreversible set. Two names on every schema change, one of them senior. Migrations designed in two steps, so we added a column and backfilled it in one deploy and dropped the old one weeks later, never both at once. Restores tested on a real schedule instead of assumed to work because the backup job was green.
None of that was elegant. It was the cheapest insurance we ever bought, and it cost us maybe an hour a week of senior attention.
The speed is real. The risk just moved.
I'm not going to tell you AI-written code is garbage. It isn't. A competent operator with good models produces working software faster than a five-person team did in 2019, and if you're paying for a fast MVP you are getting a real thing for real money. That part of the pitch is honest.
What hasn't gotten cheaper is the cost of a confident, fast, wrong operation against the only copy of your customer data. And an agent is confident by construction. It doesn't get the small queasy feeling a senior engineer gets at 11pm before typing a command with DROP in it. It doesn't pause to wonder whether the staging database it thinks it's connected to is actually production.
So the question you should be asking a dev shop is not "is your code good." You can't evaluate that and you shouldn't pretend to. The question is: who owns the operations that can't be undone?
You can absolutely evaluate the answer to that one.
What to put in the contract
Five things. Ask for them in writing before you sign, not after the first incident.
- Backups exist and a restore has been performed in front of you at least once, with a documented restore time. "We have backups" means nothing. A backup nobody has restored is a hope.
- No agent, script, or contractor tool holds write credentials to production data by default. A named human approves each time.
- Migrations are two-step and reversible. Add and backfill first, destroy later, never in the same deploy.
- There's an audit trail of what ran against production, when, and triggered by whom or what. This is the boring version of what that live diff tool is doing, and you want it whether or not anyone uses a fancy TUI.
- On the last day of the engagement you receive credentials, backups, and the full migration history. Not a Loom walkthrough. The artifacts.
If a shop pushes back on all five, that isn't a philosophical difference. They've never had to explain a data loss to a board.
What your first technical hire is actually for
It is not to type faster than the model. That contest is over.
Your first engineering hire, or your fractional CTO, exists to be the person whose name is on the operations you can't undo. That's the job description now. Someone with enough scar tissue to stand between a fast, capable, tireless agent and the one copy of your customer table, and to say "not like that, not today."
Git has undo. Your user table, your Stripe ledger, and your customers' patience do not.
Buy the speed. It's worth buying. Just make sure you know the name of the person accountable when it goes somewhere irreversible, and that the name isn't yours by default.
If you're about to sign with a shop and want someone to read the contract and the database next to you, that's most of what a two-week fractional CTO sprint ($4,500) gets used for. Cheaper than the cleanup, every time.