Migrations are getting messy — and AI is making it worse

A new post from Dan Luu warns that AI is quietly eroding the practice of writing migrations. The core problem is that models will generate working SQL on a first pass, but they don't actually understand the table, the constraints, or what happens at 2 a.m. when the schema changes while traffic is still flowing. The result is a growing pile of migrations that look fine until someone tries to run them in production.

The piece traces a real pattern: teams start using AI to write DDL, ALTER statements, and seed data, and it's fast — too fast. The models don't flag things like foreign keys getting dropped, indexes disappearing, or the difference between a migration that can be backfilled and one that will lock a large table for hours. What you get is a false sense of confidence. The code compiles. The tests pass in a sandbox. Then it breaks in the real database, and nobody on the team caught it because the AI didn't know to look for it.

The practical advice is blunt: treat AI-generated migrations like any other generated code. Run them through the linter, diff the output by hand, check the execution plan, and have a second person review the SQL before it touches production. If you're running PostgreSQL, make sure your migration tool actually supports safe, reversible changes. Don't let the speed of generation replace the discipline of review. The models are good at syntax; they're bad at consequences.

Why this matters for us: a lot of us are solo founders, small shop owners, or freelancers running our own stacks — if AI migrations slip into production without review, the downtime costs us directly.