Two lanes for an agent-written migration
A coding agent can produce a migration file faster than you can read the schema dump. That speed is useful right up to the moment the script touches a table that holds real rows. From then on, the question is not whether the agent can write SQL, but which lane you let it run in.
Two lanes show up in real teams. In the draft lane, the agent writes the migration, a human reviews it, it runs against a disposable database, and a human applies it. In the owner lane, the agent writes the migration and applies it too, reading errors and rerunning until the suite is green. Both are workable. They differ in what a mistake costs.
The draft lane looks like this:
- The agent reads your schema files and writes one migration with a matching rollback.
- You review the file in a pull request like any other change.
- You run it against a throwaway copy of the database before touching anything shared.
- A human decides when to apply it, and a human decides when to roll back.
The owner lane looks like this:
- The agent writes the migration and runs it through your migration tool.
- It reads the error output, patches the script, and reruns it.
- It repeats until the application tests pass.
- It marks the task done and moves to the next file.
The owner lane is seductive on a greenfield branch where the database holds nothing you care about. On a shared database it is the wrong default. A failed ALTER can leave a half-applied change on engines that do not roll back DDL cleanly, and an agent that retries after a failure may paper over the gap instead of surfacing it. The draft lane keeps the destructive decision in human hands, which is exactly where it belongs.
A migration contract to hand the agent
Whatever lane you pick, the agent needs rules written down before it opens a file. A short contract in the prompt or in a repository document removes most of the argument later, because you can point at a line when the output drifts.
- Name the database engine and the schema tool, so the agent writes the right dialect rather than generic SQL.
- Require the expand and contract pattern: add new columns and tables first, move data second, drop old structures only in a later release.
- Forbid drop table, drop column, truncate, and blanket updates unless the change is explicitly flagged for review.
- Ask for a rollback script for every forward script, and ask the agent to say when a rollback is genuinely impossible.
- Require batching for data backfills, with a stated key ordering so the work is resumable.
- Ask for a plain-language list of assumptions at the top of the response: table sizes, nullable columns, existing indexes.
That last item is underrated. When the agent says out loud that it assumed a column is nullable, you can check that assumption in seconds. When it stays silent, you find out in production.
Dry run on a database nobody will miss
Every agent-written migration deserves a rehearsal on a disposable copy before it goes anywhere near shared data. This is the step teams skip when a change looks trivial, and it is the step that catches the boring failures: a collation mismatch, a missing extension, a constraint that already exists under another name.
- Restore a recent copy into a scratch database, or generate one from schema plus seeded fixtures.
- Apply the migration exactly as the deploy would, using the same migration tool and the same credentials model.
- Run the full application test suite against the migrated copy, not just the migration tests.
- Run the rollback script once, then the forward script again, so you know the pair really is reversible.
- Inspect the resulting schema and compare it with what the agent described in its summary.
If the rehearsal takes longer than expected, that is information about the migration, not about your patience. A backfill that is slow on a scratch copy will be slower on real data, and the fix belongs in the script.
Review checklist before the green light
With the dry run passed, the review itself is a checklist rather than a debate. Read the file with these questions open, and stop the apply on any answer you do not like.
- Data loss: does anything drop, overwrite, or narrow a type in a way that silently truncates values?
- Locks: will this rewrite or reindex a busy table, and does the script avoid holding a long exclusive lock while doing it?
- Defaults: is a new NOT NULL column added with a default, and does that default make sense for existing rows?
- Indexes: are supporting indexes created for new foreign keys and for the columns the backfill filters on?
- Transactions: are statements grouped so a mid-script failure leaves nothing half-written, and does the engine actually support that for DDL?
- Idempotency: can the script run twice without error, in case a deploy is retried?
- Rollback: is the down script tested, and is the operational path to run it documented?
When a checklist item fails, send it back to the agent with the exact line. Agents fix pointed feedback well and vague feedback badly.
Choosing the model for schema work
Migration writing rewards a model that reads a whole schema carefully and respects a written contract over one that guesses from a single table. A capable model such as Claude Sonnet 5.5 handles the constraint reasoning and the expand and contract sequencing well, and a fast model like Gemini 3.8 Flash is handy for the mechanical passes where you rewrite a batch size or add a missing index after review comments.
You can run both through one endpoint. SwiftRelay is a pay-as-you-go relay for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and other models, and it works with Claude Code, Codex, Gemini CLI and any OpenAI-compatible SDK. Point Claude Code and Gemini CLI at the bare host https://api.fastapirelay.com, and add /v1 when you use an OpenAI SDK. Billing is per token, so a careful review loop costs only the tokens it uses. New accounts get a small gift credit, and inviting friends earns 14 percent of their top-ups. Sign up for SwiftRelay and you can keep the same review workflow across whichever model suits each migration.
The recommendation: draft lane first
Here is the call. Let the agent write the migration, and keep the apply in human hands: draft lane, contract in the prompt, dry run on a scratch copy, then the checklist, then apply. Give the agent tool access for read-only schema inspection and for running tests, but withhold credentials that can alter a shared database until the checklist is green.
The owner lane earns a place only on disposable environments, where an agent can iterate freely and the worst outcome is a rebuild. Everywhere else, the twenty minutes of review is the cheapest insurance you will ever buy for your data.