A migration is one of the few kinds of code where a subtle mistake can be irreversible against real data, which makes it a bad place to extend the same trust a model earns on ordinary application code.
Where the mistakes actually cluster
- Assuming the table is small. A migration that locks a table for the duration of a rewrite is fine on a development database with a thousand rows and catastrophic on a production table with two hundred million.
- Forgetting existing data when adding a constraint. A model will happily add a NOT NULL constraint or a foreign key without checking whether current rows would violate it, because the migration compiles and runs cleanly against an empty or synthetic database.
- Irreversible operations presented as reversible. A rollback script that drops a column loses data a forward-only reader would not expect to be at risk, and a generated rollback often mirrors the forward migration structurally without considering that asymmetry.
- No plan for concurrent writers. A migration that assumes it is the only thing touching the table during a deploy window is a fine assumption on a low-traffic staging database and a dangerous one in production.
Why these specific mistakes and not others
Training data for migrations skews heavily towards small, illustrative examples — tutorials, starter projects, toy schemas — where none of the above matters. A model reproduces the patterns it has seen most, and it has seen far more small-table migrations than large-table ones.
A migration that would work fine against an empty database is not evidence it will work against your database. It is evidence it will work against an empty database.
The check we now run on every generated migration
Before anything reaches a review queue, we ask: what does this do against a table the size of our largest production table, and what happens if it is interrupted halfway through. Those two questions catch the large majority of the problems above, and they are cheap enough to ask on every migration rather than only the ones that look risky.
What we still do by hand
Any migration touching a table above a size threshold we set per project gets a human-written plan for how it runs without a maintenance window — batched, online, with a defined stopping point if it needs to pause. We use a model to help draft that plan, not to decide unsupervised that the naive version is good enough.