An AI coding assistant that writes solid, well-structured application code can still generate a database migration that's technically valid SQL and operationally dangerous. The gap isn't about the assistant's general competence, it's about what kind of context migrations require that application code mostly doesn't.
Application code fails visibly. Migrations fail invisibly, then permanently.
Most application code bugs surface quickly: a test fails, an error gets thrown, a user reports something broken. A migration that locks a table for longer than expected, or drops a column that a still-deployed older version of the application still reads, can fail in ways that don't show up until it's already running against production data, at which point some of the damage isn't cleanly reversible the way a bad application code deploy usually is.
The assistant doesn't know your table's actual size
A migration that's perfectly safe on a table with ten thousand rows can cause a multi-minute lock, and a real outage, on the same operation against a table with forty million rows. An AI assistant generating a migration typically has no visibility into your actual production data volume unless you explicitly tell it, which means it defaults to generating the straightforward version of an operation without knowing whether that version is safe at your actual scale.
This is fundamentally a context problem, not a competence problem. The assistant isn't making a mistake so much as answering a slightly different question than the one that actually matters: "is this SQL correct" instead of "is this SQL safe to run against this specific table right now." PostgreSQL's own documentation on explicit locking is worth reading in full if you want to understand exactly which operations acquire which lock levels, since that's the underlying mechanism behind almost every migration-related production incident.
Rollback isn't automatic, and assistants don't always generate it
A well-written migration includes both an "up" and a "down" path, so a mistake can be reversed cleanly. AI assistants asked to write a migration will sometimes generate only the forward direction, especially for a straightforward-seeming schema change, leaving a gap that only becomes obvious when someone actually needs to roll back and discovers there's no clean path to do it.
Explicitly requesting a rollback path as part of every migration request, and treating a migration without one as incomplete rather than optional, closes this gap directly rather than relying on the assistant to volunteer it unprompted.
Concurrent deploys complicate migrations in ways application code doesn't face
During a rolling deploy, old and new versions of an application can run simultaneously against the same database for a period of minutes. A migration that changes a column's type or removes a column entirely can break the still-running old version, even if the new version handles the change correctly. This is a genuinely subtle constraint that requires understanding your specific deployment process, not just the schema change in isolation, and it's exactly the kind of cross-cutting context an AI assistant working from a single migration file doesn't have visibility into.
Photo by Vitaly Gariev on Pexels
Index changes are a quiet source of production incidents
Adding an index sounds like a purely additive, low-risk change, and on a small table it usually is. On a large table, building an index can lock writes for an extended period unless it's built with a non-blocking option specific to your database engine, like the CONCURRENTLY option documented in PostgreSQL's guide to building indexes. An AI assistant that generates a straightforward CREATE INDEX statement without the concurrent-safe variant isn't wrong about the SQL syntax, it's just missing the operational context about what happens when that statement runs against a large, actively written table.
MySQL and MariaDB have their own equivalent mechanisms for building indexes and running schema changes without holding a full table lock, covered in MySQL's documentation on online DDL, and the same principle applies regardless of which relational database you're running: the naive version of a schema change and the production-safe version are often different statements entirely, not just a matter of timing.
What actually closes this gap
The fix isn't avoiding AI assistance for migrations entirely, since a lot of migration work, especially for smaller tables and routine schema changes, is exactly the kind of task an assistant handles well. The fix is providing the missing context explicitly: table size, whether the table is actively written to during business hours, your deployment model, and an explicit requirement for a rollback path on every migration, stated once in your project instructions rather than repeated on every request.
"Migrations are where I've seen the biggest gap between how confident an AI-generated suggestion looks and how much operational context is actually missing from it. The SQL is rarely wrong. The assumptions about your specific table and your specific deploy process are where it goes sideways." - Dennis Traina, founder of 137Foundry
Automated checks catch what context alone doesn't
Beyond providing better context upfront, an automated check that flags any migration touching a table above a certain row-count threshold, or any migration missing a corresponding rollback file, catches the cases where context still wasn't enough. This kind of check doesn't require understanding the migration's actual purpose, just applying a mechanical rule that happens to correlate strongly with the operations that cause real incidents.
Treating migrations as their own review category
Migrations deserve a distinct review posture from typical application code changes, regardless of whether they were AI-assisted or hand-written, precisely because the failure mode is harder to catch in a normal code review and harder to undo once it's shipped. The fuller breakdown of what a layered guardrail system looks like across migrations, authentication, and billing code together is in 137Foundry's guide to setting up AI coding assistant guardrails.
Getting the process right before it becomes a real incident
137Foundry works with engineering teams to set up exactly this kind of migration-specific review process, from the automated checks that catch dangerous operations before they run to the context templates that give an AI assistant what it actually needs to generate a genuinely production-safe migration on the first attempt rather than the second, post-incident one.
A practical starting checklist for any AI-assisted migration
Before merging any AI-generated migration, four quick questions catch most of the risk: does it include a working rollback path, does it touch a table above your team's defined size threshold, does it run during a window when concurrent old and new application versions might both be active, and does it use the non-blocking variant of any index or column-type operation where one exists. None of these require deep database expertise to check, they just require remembering to ask them every time rather than only after a migration has already caused a problem.
Why this gap tends to close naturally over time
Teams that adopt AI coding assistants for migration work usually go through a learning curve: the first few incidents or near-misses teach the team which context to provide upfront, and after that the failure rate on migrations drops substantially, not because the assistant got smarter, but because the team got better at supplying the operational context the assistant needed all along. Front-loading that context deliberately, rather than learning it incident by incident, is the whole point of treating migrations as their own reviewed category from the start.
Top comments (0)