AI compatibility
Writing a zero-downtime migration for a drifted production DB is too risky to hand off to AI alone.
A human should do this one.
Average across 1 submission.
The honest read
This task sits at the intersection of irreversible production risk, missing live context, and judgment calls that require deep knowledge of the specific application's data semantics. An AI can draft migration boilerplate, but the critical decisions—which columns are truly orphaned, whether an index is safe to add concurrently, whether data validation will block deploys—require human verification against live schema state, query plans, and application behavior. Getting this wrong on a 50 GB production database is not recoverable without significant downtime or data loss.
Aggregated across 1 submission.
The five dimensions
Repeatability
LowEvery schema drift situation is unique: the specific orphaned columns, their data dependencies, the query patterns driving index needs, and the deployment constraints all differ per codebase. This is a one-off forensic and engineering task, not a repeatable pattern.
Ambiguity Tolerance
LowSuccess criteria sound clear ('zero downtime, remove debt') but are deeply ambiguous in practice: what counts as 'orphaned' depends on application code the agent cannot fully audit, and 'zero downtime' has strict technical requirements (CONCURRENTLY indexes, lock timeouts, batched deletes) that vary by Postgres version and table size.
Data & Tool Availability
LowThe agent would need live schema introspection, the full Rails codebase, query logs to confirm index candidates, and production Postgres version details—none of which are provided. Without these, any migration written is speculative and potentially dangerous.
Error Cost
HighDropping a column or table that is still in use causes immediate application failures; adding an index without CONCURRENTLY on a 50 GB table locks writes for minutes. Mistakes here are production outages or data loss, not easily reversible.
Human Judgment Required
HighDetermining whether a column is truly unused requires reading application code, background jobs, and external integrations—not just schema inspection. A senior engineer must sign off on each removal decision and validate the deployment strategy against the specific infrastructure.
What an agent would need
- Full live PostgreSQL schema dump and current Rails migration history to identify actual drift
- Application codebase access (including background jobs and API consumers) to confirm columns/tables are truly unused
- Production query logs or pg_stat_user_indexes data to validate which foreign keys are frequently queried
- Postgres version and replication topology details to determine safe index-creation and lock-timeout strategies
- A staging environment that mirrors production size and load for pre-deployment validation
Best-matched agent type
The kind of agent this work would call for if it were a fit. For this task, it isn't.
Run your own fit check
Get a calibrated read on your specific task in under a minute.