A junior engineer on a team we worked with asked an AI coding assistant to "clean up the unused columns" in a staging database. The assistant found three columns nobody referenced in the codebase, wrote a migration to drop them, and then, because the tool had shell access and an unclear scope boundary, ran it. One of those columns was read by a nightly reporting job that lived in a different repo. Nobody found out until the report came back empty three days later.
Nothing about that story requires the assistant to be malicious or even wrong. It was right that the columns looked unused from where it was standing. The failure was architectural: nothing stopped it from moving straight from "I found a problem" to "I changed production state" without a human in between.
This is the boundary most teams get wrong when they adopt AI coding tools. The question isn't whether the assistant is good at writing migrations. Increasingly, it is. The question is what it's allowed to do with that migration once it's written.
Why migrations are a special case
Most AI-assisted changes are reversible by re-running the assistant or reverting a pull request. Database migrations are not always reversible in that same clean way. A dropped column, a truncated table, or a changed constraint can destroy data that no version control system tracks. Code lives in git. Data usually does not.
That asymmetry is why migrations deserve stricter rules than, say, refactoring a utility function. A bad refactor gets caught in review and reverted. A bad migration that already ran against production might mean a restore from backup, hours of downtime, and an uncomfortable conversation with customers.
Photo by Adam Kring on Unsplash
The three permission tiers worth drawing
Rather than treating "AI coding assistant access" as one setting, split it into tiers based on blast radius.
Tier one: read and suggest. The assistant can read schema, read code, and propose a migration file as a diff. It cannot execute anything. This is safe for any environment, including production-adjacent staging databases with real customer data copies.
Tier two: write and run in isolated environments. The assistant can create and apply migrations against a disposable environment, a Docker Compose stack, or a scratch database seeded with synthetic data. Nothing here has downstream consequences because nothing here is shared.
Tier three: apply to shared environments. This tier requires a human to review the generated migration and run it themselves, or requires the migration to pass through the same CI pipeline every human-authored migration goes through, with the same approvals. There is no tier where an assistant applies a migration to a shared staging or production database on its own initiative.
Most of the incidents we hear about come from skipping straight to tier three because the assistant "seemed trustworthy" after a few good sessions. Trust earned on read-and-suggest tasks doesn't transfer to apply-to-shared-database tasks. Treat them as separate grants.
Give the assistant a narrower tool, not a bigger warning
Telling an AI coding assistant "please be careful with migrations" in a system prompt is a suggestion, not a control. Suggestions get ignored under ambiguity, exactly the situation that caused the staging incident above. A better move is to change what the assistant can physically do.
If your team's workflow lets an assistant run arbitrary shell commands, split migration execution into its own script that requires an explicit flag a human sets, separate from the flag that lets it run tests or start a dev server. If you use a task runner, put migrate:apply behind a target that isn't in the assistant's default allowed command list, and put migrate:generate in front of it instead. The assistant can still be useful, drafting the migration file, explaining what it does, flagging a missing index, without ever holding the credential that applies it.
This mirrors how teams already handle production deploys for humans: junior engineers can open a deploy pipeline, but the pipeline itself gates on a second approver. Apply the same shape to the assistant.
Photo by Michael Burrows on Pexels
Make the generated migration easy to review, not just possible to review
A ten-line migration that adds a nullable column is easy to eyeball. A generated migration that touches five tables, backfills data, and adds a constraint is not, and reviewers under time pressure will skim it the same way they'd skim the small one. That's how mistakes get through review instead of getting caught by it.
Ask the assistant to explain its own migration in plain language as a required part of the pull request: what tables change, whether the change is reversible, whether it needs a backfill step, and what happens to existing rows that don't satisfy a new constraint. This isn't busywork. It forces the assistant to surface exactly the details a human reviewer needs and would otherwise have to reconstruct by reading raw SQL.
"The migrations that cause outages are rarely the ones anyone argued about in review. They're the ones that looked routine enough that nobody read past the first three lines." - Dennis Traina, founder of 137Foundry
Version-control the schema state the assistant reasons from
A recurring source of bad AI-generated migrations is a stale mental model of the schema. If the assistant is working from a schema dump that's a week old, or inferring the schema from application code that lags the real database, it will generate migrations that conflict with columns or constraints added since. Before letting an assistant draft anything, give it a fresh, generated schema reference (from your ORM's introspection tools or a direct pg_dump --schema-only equivalent) rather than trusting it to remember or guess.
This matters more as teams scale. A two-person project can keep the schema in someone's head. A team with a dozen contributors and a migration a day cannot, and an assistant working from outdated assumptions will confidently generate a migration that would have been correct last week.
Photo by Mahmoud Zakariya on Pexels
Log every migration the assistant proposes, applied or not
Keep a running log, even a plain markdown file in the repo, of every migration an AI assistant proposed: what it was, whether a human approved it, whether it ran, and what happened when it did. This isn't about surveillance. It's about having a paper trail when something goes wrong three weeks later and nobody remembers whether the column drop was reviewed carefully or rubber-stamped at 6pm on a Friday.
Over time this log becomes useful in a second way: it shows you where the assistant's migration suggestions are consistently good (safe to give more autonomy) and where they consistently need correction (a signal to tighten that tier's guardrails further, or to write a project-specific style guide the assistant should follow for that class of change).
Photo by Brett Sayles on Pexels
What this looks like in a real pipeline
A pattern we've seen work well: the assistant drafts the migration file locally and runs it against a disposable Compose database seeded from a synthetic fixture set, never a copy of real data. It writes a plain-language summary as part of the commit message. A human reviews the diff and the summary, and if approved, the CI pipeline (not the assistant) applies the migration to staging, then production, through the exact same gated deploy process a human-authored migration would go through. The assistant never holds staging or production credentials at any point in that chain.
This keeps the AI coding assistant genuinely useful. It's often faster at drafting the boilerplate, catching an obviously missing index, or noticing that a new NOT NULL column needs a default for existing rows, than a human doing it from scratch. It just never becomes the thing that pulls the trigger on a shared database.
Building this into your existing workflow
If your team already uses feature flags or staged rollouts for application code, migration guardrails are the same idea applied one layer down. Our AI automation service helps teams design exactly this kind of tiered access for AI coding tools, matched to how your CI and deploy pipeline already work rather than replacing it. If migrations aren't the current risk area but data pipelines or integration jobs are, the same tiering logic applies there too, and our data integration service covers that ground specifically.
The broader principle holds regardless of which part of your stack an AI assistant touches: separate "the assistant can propose this" from "the assistant can execute this" as two distinct permissions, and require a human or a pipeline, never the assistant alone, to bridge that gap for anything that isn't trivially reversible. Migrations are just the sharpest example, because the cost of getting it wrong is data, not just time.
For teams still figuring out where to draw these lines across their broader engineering process, our services hub has more on how we approach AI-assisted development without turning it into an unsupervised production risk. You can also read more about 137Foundry and how we think about pairing automation with the guardrails that keep it safe to use.
Further reading on the underlying database concepts: the PostgreSQL documentation covers transactional DDL and constraint behavior in more depth than any summary here can, and the Django migrations documentation is a good reference if your stack uses an ORM-managed migration flow. For a broader view of safe schema change practices, Martin Fowler's site has long covered evolutionary database design as a discipline separate from any one tool.
