The AI Wasn't Writing Code. It Was Running the Operation.

TL;DR: One of the most useful things we did with an AI coding CLI this year wasn't writing code. It was running a high-stakes database migration as the operator. The AI read the system, wrote a plan, survived an adversarial review, took backups, rehearsed on a copy, and verified the data was provably identical. We approved every irreversible step. The real frontier isn't autonomy. It's leverage under control.

It started with a small wish. We wanted to put the blog on the Fediverse, to make it followable from the open social web instead of locking our reach inside someone else's feed. A weekend errand, we thought. Flip a switch, done.

It was not a weekend errand. The small wish, as small wishes do, had a much larger thing hiding behind it. To get there, we had to upgrade the platform across a major version, and that upgrade meant migrating the database underneath a live site to an entirely different engine. The cosmetic feature was sitting on top of a real infrastructure migration.

This is the moment every engineer knows. The pull request you thought would take an afternoon turns into a careful, slightly nerve-wracking operation with backups, maintenance windows, and the quiet fear of corrupting something you can't get back. The danger here isn't difficulty. It's tedium. You make expensive mistakes on the boring steps because the boring steps are where attention goes to die.

So we did something we hadn't really done before. Instead of grinding through it by hand, we ran the whole operation through an AI coding CLI, and we treated it not as a code generator but as the operator.

What happened changed how we think about these tools.

Beyond Autocomplete: What AI Coding Tools Actually Did

Most people meet AI coding assistants as a fancy autocomplete. You're in a file, you want a function, it writes the function. Useful, narrow, and easy to dismiss once the novelty fades.

A migration like this barely involves writing code. It's something else entirely. It means reading an unfamiliar system and understanding how its pieces fit. It means noticing that a "simple feature" actually requires three layered prerequisites, and saying so before touching anything. It means researching the official documentation instead of guessing, weighing trade-offs, sequencing steps that can't be undone, and knowing which actions are safe and which are one-way doors.

That's not coding. That's operations. Sysadmin work. The unglamorous connective tissue that keeps systems alive, and the exact kind of work we assumed still belonged entirely to humans.

The first thing the tool did was the thing we, under deadline pressure, are most tempted to skip. It looked before it leaped. It read the running system, mapped the moving parts, and reframed the request. Not "turn on the feature," but "perform a migration that happens to enable the feature."

That reframing alone was worth more than a thousand generated functions. It's the difference between an assistant that helps you and one that lets you walk off a cliff confidently.

The Discipline, Not the Magic

Here's the part we want to be honest about, because the honest part is the whole point. What made this work wasn't intelligence. It was discipline. And discipline is something you can ask an AI to follow relentlessly, without it getting bored.

The operation followed the playbook a meticulous engineer would run on their best day. Step by step, it looked like this:

1. It wrote a plan and let an adversarial review tear it apart before a single production command ran. The review found real flaws. The plan got fixed.
2. It took backups. No skipping, no "probably fine."
3. It rehearsed the entire migration on a disposable copy of the system, watched it succeed end to end, and only then approached the real one.
4. It verified the migrated data against the original with the suspicion of someone who's been burned before. Not "looks fine," but "is provably identical."
5. It kept every step reversible, so at any moment we could walk it backward to exactly where we started.

The cutover carried an extra safety belt. It proved the migrated data was faithful through the application's own eyes before committing to the version it couldn't easily undo. The actual downtime was a handful of minutes, and most of that was verification we chose to keep rather than rush.

None of that is clever. All of it is careful. And careful is precisely the quality humans lose around hour three of a tedious procedure.

An AI doesn't lose it. It runs the same paranoid check on the live system that it ran in rehearsal. It doesn't talk itself out of the backup. It is, in the most literal sense, a tireless junior operator who actually follows the runbook.

It Wasn't Flawless, and That's Reassuring

We're not interested in selling you a fantasy where the machine never errs. It did make mistakes along the way. The reason they didn't matter is that the process was built to make mistakes loud and cheap. A step would fail visibly, the failure would point straight at the cause, and a correction would land moments later.

That's the real lesson, and it's an old one wearing new clothes. You don't make systems safe by demanding perfect operators. You make them safe by building a process where errors surface immediately and reverse easily.

An AI that never makes a mistake is something you should distrust. An AI embedded in a process that catches mistakes fast is something you can actually put to work.

The Human Stays on the Wheel

There's a version of this story that ends with "and then we let the AI run the infrastructure." That is not our story, and we'd argue against it.

Throughout, the shape was the same. The AI proposed, and a human approved. The AI did the reversible, local work. The humans kept the irreversible and the outward-facing decisions. An external panel argued with the plan before it executed. A person chose when to pull the trigger. At no point was anyone handing over the keys. We were handing over the legwork.

This matters beyond this one migration. The interesting future of these tools isn't autonomy. It's control with leverage. The AI is the one who never tires of the checklist, who reads the whole manual, who runs the rehearsal you'd have skipped. You are the one who decides what's worth doing, what's too risky, and when. That division of labor is where the real gains live.

How to Point an AI at Your Own Infrastructure

If you've only ever used an AI coding CLI to finish your sentences, this is the part worth hearing.

Point one at your infrastructure. Not recklessly. Wrap it in exactly the discipline you'd demand of a careful junior you don't fully trust yet:

• A written plan before any command runs.
• A second opinion, ideally adversarial, that tries to break the plan.
• A backup you've confirmed, not assumed.
• A rehearsal on a copy of the system, run end to end.
• Reversible steps, so any moment can be undone.
• Your own hand on the final switch.

Used that way, these tools turn the scariest, most procedural parts of operations into something calm and repeatable.

We went looking to join a social network and accidentally learned something bigger. The frontier of these tools isn't how much code they can write. It's how much of the careful, boring, high-stakes work around the code they can carry, while you stay firmly in command.

The migration succeeded. The blog is on the Fediverse now. But the thing we'll remember is that the AI spent the day not as a coder, but as the most patient operator we've ever worked with. And it never once reached for the keys.

FAQ

Can an AI coding tool safely run a database migration?

Yes, if you treat it as an operator inside a disciplined process rather than an autonomous agent. In our migration, the AI wrote a plan, survived an adversarial review, took backups, rehearsed on a disposable copy, verified the data was provably identical, and kept every step reversible. A human approved each irreversible action. The safety came from the process, not from trusting the AI to be perfect.

What's the difference between using AI for coding versus operations?

Coding is writing functions and finishing your sentences in an editor. Operations is reading an unfamiliar system, sequencing steps that can't be undone, researching documentation, and knowing which actions are one-way doors. We found AI far more useful for the operations work, because that work is mostly disciplined, tireless checklist execution, which is exactly what an AI doesn't get bored of.

Should you let an AI run infrastructure on its own?

No. Our entire argument is against autonomy. The AI did the reversible, local legwork while humans kept the irreversible and outward-facing decisions. The goal is leverage under control, not handing over the keys. A person should always choose when to pull the trigger on actions that can't easily be undone.

How do you make AI-driven operations safe?

Build a process where mistakes surface immediately and reverse easily. Use a written plan, an adversarial second opinion, confirmed backups, a full rehearsal on a copy, reversible steps, and a human on the final switch. An AI that never makes mistakes should make you nervous. An AI inside a process that catches mistakes fast is one you can actually put to work.

What was the actual downtime during the migration?

The real downtime was a handful of minutes, and most of that was verification we chose to keep rather than rush. Before committing to the new version, the process proved the migrated data was faithful through the application's own eyes, so the cutover itself was fast and low-risk.