A coding agent can help draft a database migration, but schema and data changes deserve more care than an ordinary refactor. A migration may lock a table, fail on existing records, lose information, or behave differently on a clean database than on a real upgrade. Keep the agent away from production credentials and test the migration from a representative starting state.
Describe the current and desired data shape
State which application behavior needs to change, what the existing schema looks like, and how existing rows should be handled. Ask the agent to find the project’s migration framework and naming conventions before creating a file. Include constraints such as preserving user data, supporting older application versions during deployment, and keeping the migration reversible when that is actually possible.
Ask for an explanation of the migration before it is applied. Review whether it adds or removes a column, changes nullability, alters a type, creates an index, or transforms stored values. A syntactically valid migration can still be unsafe for the amount and shape of data in a real system.
Use a disposable database for the first run
Run the migration on a fresh local or temporary database, then test the upgrade path from a database that resembles the previous application version. A clean schema catches setup mistakes. Existing sample data catches assumptions about null values, duplicates, old formats, and required backfills.
Never give an agent a production connection string for a routine code task. Put a disposable database in the environment and verify the target before every command. If a migration requires a data backfill, inspect the exact query and consider whether the application needs a staged rollout.
- Create a branch and confirm the database target is disposable.
- Ask the agent to explain the migration plan before editing.
- Test both a new database setup and an upgrade from an older fixture.
- Check data preservation, constraints, indexes, and application compatibility.
- Review deployment and recovery steps with the database owner.
Do not assume rollback can restore lost data
Some schema changes can be reversed cleanly. Others cannot restore information that was discarded or transformed. An automatic down migration is not proof that the data can be recovered. Prefer a backup, a staged change, or a forward correction plan when rollback would lose user data.
Consider the production sequence. Large table changes, locking behavior, replication, old application versions, and the duration of a backfill can matter more than the migration file itself. The agent can help list these concerns, but someone responsible for the database should approve the release plan.
Review the patch and run the project checks
Inspect the generated migration, the model or schema changes, and any updates to fixtures or tests. Make sure tests still fail when the old behavior is present and pass after the migration. Run the repository’s documented migration checks and look for unrelated edits.
For general agent workflow, use a clean Git checkpoint and verify the exact diff. For a security sensitive database, limit network access and secrets in the same way you would for any agent that can execute commands.