AI Coding Agents
Platform Engineering
Safer database migrations with coding agents
September 24, 2026 - 2 minute read
Database migrations with coding agents combine code generation with operational risk. A coding agent can edit schema definitions, application queries, backfill jobs, and tests, but the production database has state that does not exist in the repository. Safe automation keeps those two realities visible.
The established parallel-change pattern breaks an incompatible change into expand, migrate, and contract phases. Martin Fowler's description of parallel change emphasizes maintaining compatibility while callers move to the new interface. That sequence also gives a coding agent smaller tasks with clearer evidence.
Plan database migrations in phases
Start by writing the invariant that must remain true during deployment. For a column replacement, old and new application versions may need to read the same logical value. For a new constraint, existing rows must satisfy it before enforcement.
Ask the agent to produce separate changes for each phase:
- Expand. Add backward-compatible schema and code paths.
- Migrate. Backfill data in bounded batches and measure progress.
- Contract. Remove the old path only after every reader and writer has moved.
Keep deployment and destructive operations outside the coding task unless they are explicitly authorized. The pull request should contain migration code, tests, operational notes, and rollback conditions. It should not run against a shared database merely because the agent can reach one.
Validate database migrations with coding agents
Run schema changes against an isolated database populated with representative data shapes. Include nulls, old enum values, duplicate keys, long rows, and partially migrated records where those states are possible. PostgreSQL's ALTER TABLE documentation shows that lock behavior and validation options vary by operation, so the review must consider the actual database and statement.
Require evidence at three levels. Static checks confirm that migrations are ordered and reversible where the framework supports reversal. Integration tests run old and new application paths against the expanded schema. Operational checks estimate lock duration, backfill rate, transaction size, and the signals that trigger a pause.
Factory's Missions can split a migration across planned milestones and validation checkpoints. The orchestrator can assign code, test, and review work separately while a human approves progress between phases. For pull requests, automated QA can scope test flows from the diff and preserve evidence.
Keep the production decision human
Database migrations need an owner, a maintenance or rollout plan, and a tested stop condition. Reviewers should know which statements acquire strong locks, whether the application tolerates mixed versions, and how long old data remains readable.
Use observability that reflects migration state rather than process completion. Track rows remaining, error rate, lock waits, replication lag, and application reads from the old path. A successful job exit does not prove that every record migrated correctly.
Coding agents are effective at the repeatable parts: locating callers, generating compatibility edits, writing fixtures, and running checks. Humans retain the production decision because workload timing, customer impact, and rollback tradeoffs depend on live conditions.
