The Migration Gate Is the Right Idea. The Reference Script Certifies Syntax.

A post on dev.to, headlined "Why AI-Generated Migrations Need a Different Gate Than Code Patches", argues that schema changes need a pre-merge gate separate from ordinary AI-generated code, because the usual patch checks - generated tests pass, diff is small, fixtures still match - are blind to irreversibility ^[1][2]. The argument is right. The reference implementation shipped with it does not enforce the check the author calls most important. The asymmetry is the whole case. A code change can usually be reverted by applying the old diff again, while a migration that drops a column, truncates a table, or rewrites data may leave the previous state unrecoverable even after the commit is reverted ^[3]. So the review question shifts from "does this behave the way we intended" to "what does this make impossible to undo" ^[4]. The author names three migrations that pass a conventional patch gate: one that drops a column and ships no down.sql; one whose down.sql recreates the column but cannot restore the data; one that is valid SQL and therefore green in CI but fails against a real schema with existing locks, ordering constraints, or indexes ^[5]. The end state described is familiar: a reviewer approves a reasonable-looking ALTER TABLE, CI is green, and then production data disappears or the deploy stalls while the DDL waits on a lock ^[6]. The proposed gate has three stages: a destructive keyword scan, a shadow apply of up.sql against a throwaway database, and round-trip schema parity by applying down.sql and comparing the schema snapshot with the baseline ^[7]. The author calls the third one the important check, on the grounds that a down migration which cannot restore the original schema means the up migration is a one-way door a human should be forced to approve explicitly ^[8]. Disclosure carried in the piece: it was prepared as part of MonkeyCode's product outreach, and the author declines to quote quota or hardware specifics because those change ^[9]. The script is offered as a runnable starting point, not a guarantee ^[10]. Read the script, because parity is not what it measures. The baseline snapshot is taken from the base URI, the example being the postgres maintenance database; a shadow database is then created with a bare CREATE DATABASE and up.sql is applied to it ^[11]. Nothing loads the baseline schema into the shadow first, so the final comparison is between snapshots of two different databases ^[1]. Both snapshots come from pg_dump --schema-only, so a down.sql that recreates a column and leaves it empty passes round-trip parity - which is exactly the second of the three failure modes ^[2]. The third mode fares no better: the script loads no data and runs its statements serially with no other client, so lock waits under production traffic are not reproduced ^[3]. Of the three named modes, only the first is reliably caught, and only because a missing down.sql makes psql fail and the helper exits with the subprocess return code ^[4]. The failure printout is decorative: diff is invoked as ["diff", "-", "-"] with both snapshots concatenated into a single stdin stream ^[12][5]. The keyword scan drifts too. The prose lists DROP TABLE, TRUNCATE and unguarded UPDATE; the code list is DROP TABLE, DROP COLUMN, TRUNCATE, DELETE FROM, with no UPDATE in it ^[13][14][6]. It is an uppercased substring test with no SQL parsing, so it fires inside comments and string literals and misses a DROP COLUMN split across a line break ^[7]. The part worth keeping is the escalation rule: a non-empty blocker list should not auto-reject, it should move the change into destructive-review mode with an explicit note on what data is lost ^[15]. That is policy, and policy is cheap to adopt today. What to watch is whether anyone building this pipeline restores a real baseline into the shadow database and adds a data round trip rather than a DDL-only one.