AI can write a working migration in about thirty seconds. I've watched it happen — paste in your schema, describe the change, and out comes a clean ALTER TABLE with a rollback plan attached. It's impressive. It's also one of the places I'm most reluctant to hand over the wheel, and I want to explain exactly why — because my hesitation isn't reflex caution. It's earned.
What "Writing a Migration" Actually Involves
A database migration isn't just syntax. It's a judgment call about a live system you can't easily pause. When you write one by hand, you're implicitly asking yourself a chain of questions:
- How large is this table, and will an
ALTERlock it long enough to cause downtime? - Do any background jobs or read replicas touch this column right now?
- What happens to the rows that were written between deploy and backfill?
- Is this migration truly reversible, or does the down migration silently lose data?
- What's the blast radius if it fails halfway through?
An AI doesn't know the answers. It doesn't know your table has 800 million rows. It doesn't know your ORM holds a schema cache that won't reflect the rename until the next process restart. It doesn't know your staging database is a 5% sample that never surfaces lock contention. It generates plausible SQL — and plausible is exactly the wrong bar for a migration that touches production data.
The Case for Using AI Here (Steel-Manning It)
The strongest argument in favor is that most migrations are routine. Adding a nullable column, creating an index concurrently, renaming a rarely-used field — these are mechanical operations that experienced engineers write the same way every time. If the pattern is that well-understood, why not automate the drafting?
There's also a real safety argument: AI tends to add things humans forget. It'll include CREATE INDEX CONCURRENTLY without being asked. It'll generate the down migration alongside the up. It'll flag that renaming a column requires a multi-phase deploy if an ORM is involved. In that sense, it functions like a thorough code reviewer who's read every "how we took down production" post mortem.
I've seen teams use AI-generated migrations successfully. Usually those teams have three things in common: strong schema review in CI, a migration linting tool (like Squawk or the equivalent), and at least one engineer who reads every generated migration word-for-word before it goes anywhere near a merge queue.
Where It Actually Goes Wrong
The failure mode isn't the AI generating obviously broken SQL. It's the AI generating technically correct SQL that's wrong for your specific system, and a reviewer who trusts the generator not reading it carefully enough to catch that.
Consider a real scenario: you ask an AI to add a foreign key constraint to an existing table. It generates valid SQL. What it doesn't know — because you didn't tell it — is that your Postgres version requires a table-level lock to validate that constraint, and your table is hit by 400 writes per second during business hours. The migration is correct. The timing window it creates is not. That gap — between correct syntax and correct operations — is where AI-written migrations bite you.
The subtler danger is confidence drift. The first five AI migrations work perfectly. Engineers start reviewing them the way we review auto-formatted code — a quick skim, then approve. By migration fifteen, nobody's reading the rollback clause anymore. That's exactly when you get the one that isn't fine.
The Line I Actually Draw
Here's my working rule: AI can draft, a human must own. Those aren't the same thing, and the distinction matters.
Drafting means using AI to generate the initial SQL, the rollback, and a plain-language description of what the migration does and what could go wrong. That's genuinely useful — it's the equivalent of a junior engineer doing the first pass. The draft still goes through a full review, run against a production-scale dataset in staging, and signed off by someone who understands the operational context: table size, traffic patterns, deploy sequence.
What I won't do is let AI-generated migrations flow through a review process that's optimized for application code. Schema changes need a different checklist. Lock duration. Backfill strategy. Replica lag. Rollback viability. Those questions don't appear on most code review templates, which means they fall through the gap whether the migration was AI-written or not — AI just makes them easier to miss because the code looks so authoritative.
The Tooling Gap Nobody Talks About
What would actually make this safe isn't a better AI — it's better tooling around the AI's output. Most teams don't have automated migration risk scoring. They don't have a CI check that estimates lock duration based on row count. They don't have a required field on every migration PR that says "estimated impact on production traffic." If those guardrails existed, AI-generated migrations would be significantly safer, because the human review would be structured around the right questions instead of a vibes check.
Until that tooling exists in your stack, AI-written migrations are only as safe as your review culture — and review culture degrades under shipping pressure every single time.
Where I Land
AI database migrations belong in your workflow the same way a code generator belongs there: as a starting point that earns its place through rigorous human review, not as a trusted output. Use it to draft. Use it to catch the rollback you forgot. Use it to generate the description you'd otherwise skip writing. But own the migration — completely — before it touches a real schema.
The cost of a bad application bug is usually a bad user experience and a hotfix. The cost of a bad production migration can be data loss, hours of downtime, and a post-mortem that starts with "the AI generated it and we approved it without fully reading it." That's not a risk profile I'm willing to accept for a time-saving shortcut that saves maybe twenty minutes.
Draft with AI. Deploy with your own eyes open.
