Cuando el agente escribe una migración, la base debe decir no

Una migración de base generada por agente de IA no es solo otro diff en el PR. Cambia estado persistente y puede fallar donde el test unitario no mira: orden de deploy, locks, datos duplicados, columnas obligatorias, rollback débil y permisos excesivos.

En 2026, Stack Overflow en "2025 Developer Survey: AI" informó que el 84% de las personas encuestadas usa o planea usar IA en desarrollo, frente al 76% del año anterior; entre profesionales, el 51% la usa a diario (Stack Overflow, "2025 Developer Survey: AI", 2025, consultado el 22/07/2026). El uso ya no es novedad. La pregunta real es dónde puede actuar el agente.

Resumen práctico

• El agente puede proponer una migración, pero no aplicarla en la base real.
• CI necesita simulación, lint y evidencia antes del merge.
• Un cambio destructivo exige revisión humana, aunque los tests pasen.
• Rollback no es promesa del agente; es contrato probado.

¿Por qué una migración de agente merece un gate propio?

En 2026, GitHub Blog en "Agent pull requests are everywhere" reportó más de 60 millones de revisiones con Copilot code review, crecimiento de 10 veces en menos de un año y más de una de cada cinco revisiones con intervención de un agente (GitHub Blog, "Agent pull requests are everywhere", 2026, consultado el 22/07/2026). Una migración merece gate propio porque el coste del error no queda solo en el código.

Un agente puede cambiar modelo, ORM, query, test y archivo SQL en la misma sesión. Parece eficiencia. El riesgo es que el PR muestre coherencia local mientras la base real tiene datos antiguos, tenants activos, jobs atrasados y versiones distintas de la aplicación corriendo en paralelo.

El gate propio separa tres preguntas. ¿La migración aplica en una base descartable? ¿Es compatible con la versión anterior de la aplicación? ¿Contiene una operación destructiva, data-dependent o bloqueante? Si alguna respuesta falla, el agente vuelve al loop sin tocar producción.

Cápsula citable: Una migración generada por agente necesita gate propio porque revisión de código no prueba seguridad de estado. Con más de 60 millones de revisiones de código por Copilot en GitHub, la escala del agente exige CI que simule base, bloquee riesgo y preserve revisión humana.

Este tema continúa el harness de agentes de código para PRs confiables. Allí, el foco es el flujo completo. Aquí, el corte es el límite más caro: estado persistente.

¿Qué debe hacer CI antes de aceptar la migración?

En 2026, arXiv en "AI Agent Pull Requests on GitHub" analizó 33.596 PRs de agentes en 2.807 repositorios y encontró pares coactivos en el 40,2% de los repositorios bajo solapamiento exacto (arXiv, "AI Agent Pull Requests on GitHub", 2026, consultado el 22/07/2026). CI necesita detectar concurrencia y riesgo antes del revisor humano.

Primero, trata la migración como artefacto ejecutable, no como texto. CI debe levantar una base descartable, aplicar el estado base aceptado, correr la migración nueva, ejecutar smoke tests de lectura y escritura, comparar el schema final y adjuntar evidencia corta al PR.

Segundo, separa permiso de análisis. El agente puede generar el archivo y correr un dry-run. No recibe credencial de producción. Si la tarea necesita forma de datos reales, usa réplica sanitizada, snapshot o consulta read-only revisada por una persona.

Cápsula citable: El CI de migración agentic debe ejecutar el cambio, no solo leer SQL. El estudio de arXiv midió 33.596 PRs agentic; cuando agentes trabajan en paralelo, base descartable, lint y resumen de evidencia reducen errores que el merge textual no ve.

En runs largos, el coste de contexto entra en este contrato. Uso RemoteCode para mantener continuidad en flujos agentic de Codex y Claude Code con menos repetición de contexto cuando el agente necesita cruzar schema, logs y evidencias de CI; es una herramienta mía, así que esta mención es editorial y ligada al coste de tokens.

¿Cómo montar dry-run con shadow database?

En 2026, la documentación de Prisma en "About the shadow database" describe la shadow database como una segunda base temporal creada y borrada automáticamente por prisma migrate dev, usada para detectar drift y posible pérdida de datos (Prisma, "About the shadow database", 2026, consultado el 22/07/2026). Usa ese patrón incluso fuera de Prisma.

El dry-run debe nacer limpio. Levanta Postgres, MySQL u otra base en container, aplica migrations ya aceptadas, corre la migración nueva y compara el estado final. Luego repite desde un snapshot parecido a producción, con datos sanitizados suficientes para activar constraints.

El agente debe recibir una salida resumida. No devuelvas un dump completo al modelo. Entrega error, comando, nombre de la migración, tipo de fallo, tabla afectada y próximo límite. Eso alimenta un loop autocorrectivo sin filtrar datos ni gastar contexto con ruido.

{
  "migracion": {
    "origen": "agente",
    "ambiente": "base_descartable",
    "dry_run": "obligatorio",
    "datos_reales": "bloqueados",
    "produccion": "sin_credencial"
  }
}

Cápsula citable: Shadow database es el modelo operativo para migración de agente: crear una base temporal, aplicar historial, probar el diff y descartar el ambiente. Prisma usa ese mecanismo para drift y pérdida de datos; en CI, se vuelve límite de seguridad.

Este diseño encaja con loop autocorrectivo de agente en CI. El agente puede corregir la migración, pero solo desde feedback pequeño y verificable.

¿Qué cambios destructivos deben bloquear al agente?

En 2026, la documentación de Atlas en "Migration Analyzers" define cambio destructivo como alteración de schema que resulta en pérdida de datos, como ALTER TABLE users DROP COLUMN email_address (Atlas, "Migration Analyzers", 2026, consultado el 22/07/2026). El bloqueo debe empezar por drop, rename inseguro y constraint que depende de los datos actuales.

No todo riesgo parece destructivo en el diff. Agregar un índice único puede fallar si ya hay duplicados. Volver obligatoria una columna puede fallar si existen nulos. Renombrar una columna puede romper la versión antigua de la aplicación durante deploy azul-verde o rolling.

El agente puede sugerir un plan expand-contract: crear columna nueva, escribir en ambos lugares, hacer backfill, cambiar lectura y remover después. Pero la remoción final necesita pre-check y aprobación. Si el agente comprime todo en una sola migración, CI debe devolver fallo.

Cápsula citable: El lint de migración debe bloquear más que DROP. Atlas lista cambios destructivos, data-dependent e incompatibles; para agentes, esos alertas deben volverse error de CI, porque el modelo tiende a optimizar el diff, no la ventana operacional.

Para riesgo de herramienta, combina esto con allowlist MCP para agentes seguros. Una migración segura empieza antes del SQL: empieza en el permiso que impide al agente encontrar la credencial equivocada.

¿Dónde entran hooks, JSONL y revisión humana?

En 2026, la documentación de permisos de Claude Code afirma que hooks PreToolUse pueden negar, forzar prompt o permitir una llamada de herramienta sin saltarse reglas de permiso (Claude Code Docs, "Configure permissions", 2026, consultado el 22/07/2026). Usa hooks para negar comandos peligrosos antes de que se vuelvan hábito.

Un hook simple puede bloquear psql contra host de producción, negar DROP DATABASE, exigir confirmación para ALTER TABLE, o impedir que archivos de migration antiguos se editen fuera del último timestamp. La regla debe vivir fuera del prompt, porque prompt es consejo. Hook es política ejecutable.

En 2026, la documentación de OpenAI en "Non-interactive mode" dice que codex exec --json emite JSON Lines con eventos como thread.started, turn.started, turn.completed, turn.failed, item.* y error (OpenAI Developers, "Non-interactive mode", 2026, consultado el 22/07/2026). Guarda ese JSONL como artefacto restringido y publica solo el resumen seguro en el PR.

Cápsula citable: Prompt no es control de cambio. Claude Code permite hooks que niegan tool calls, y Codex emite JSONL para auditoría; juntos crean traza y bloqueo para migraciones agentic antes de que aparezca una credencial sensible.

Este punto conversa con observabilidad de agentes de código en CI. Si la migración falla, el revisor necesita saber si fue error de schema, permiso, dato o reintento repetido.

¿Qué contrato mínimo cabe en el próximo PR?

En 2026, arXiv en "AI Agent Pull Requests on GitHub" midió conflicto textual del 41,7% en pares cross-agent frente al 19,8% en pares intra-agent al reproducir merges reales (arXiv, "AI Agent Pull Requests on GitHub", 2026, consultado el 22/07/2026). Para migración, el conflicto textual es solo el inicio; el contrato mínimo debe probar ejecución.

Adopta un archivo agent-migration-report.json por PR. Debe declarar herramienta, commit base, migración nueva, base descartable usada, comando de dry-run, resultado del lint, riesgo detectado, plan de rollback o roll-forward, y persona responsable de la aprobación final.

También prohíbe tres atajos. El agente no edita una migración antigua sin motivo explícito. El agente no recibe URL de producción. El agente no marca rollback como listo sin ejecutar el camino de vuelta o documentar que la estrategia real es roll-forward.

Cápsula citable: El contrato mínimo para migración de agente es un reporte ejecutable por PR. Como cross-agent conflict llegó al 41,7% en arXiv, el equipo debe declarar alcance, dry-run, lint, aislamiento de datos y aprobación humana.

Si ya escribiste evals de regresión para agentes de código, agrega un caso específico para schema. El test no necesita probar todo. Necesita impedir que el agente trate la base como archivo temporal.

FAQ sobre migración de base generada por agente

¿Un agente puede crear una migración de producción?

Puede proponer la migración, pero no debe aplicarla en la base real. En 2026, Stack Overflow informó que el 51% de desarrolladores profesionales usa IA a diario (Stack Overflow, "2025 Developer Survey: AI", 2025, consultado el 22/07/2026). Ese uso pide separar generación de código y permiso operacional.

¿Dry-run sustituye revisión de DBA o backend sénior?

No. En 2026, arXiv analizó 33.596 PRs de agentes, pero el conflicto de merge todavía no cubre semántica de datos (arXiv, "AI Agent Pull Requests on GitHub", 2026, consultado el 22/07/2026). Dry-run reduce error mecánico; revisión humana evalúa impacto, ventana y rollback.

¿Puedo dejar que el agente use snapshot de producción?

Solo si el snapshot está sanitizado y tiene acceso controlado. En 2025, AI Incident Database catalogó el caso Replit como incidente de comandos destructivos durante code freeze con pérdida de datos de producción (AI Incident Database, "Incident 1152", 2025, consultado el 22/07/2026). El agente debe ver datos mínimos.

¿Qué herramienta usar para lint de migración?

Usa la que combine con tu stack. En 2026, Atlas documenta atlas migrate lint para analizar migraciones localmente y en CI contra operaciones destructivas, cambios incompatibles y locks (Atlas, "Verifying Migration Safety", 2026, consultado el 22/07/2026). Prisma, Flyway y Liquibase necesitan gates equivalentes.

Cierre

Un agente de código acelera migraciones cuando el pipeline trata la base como sistema vivo. Estorba cuando el equipo confunde SQL válido con cambio seguro.

El camino pragmático es pequeño: rama aislada, dry-run en base descartable, lint destructivo como error, JSONL restringido, hook de permiso y aprobación humana para lo irreversible. Después de eso, el agente sigue siendo útil. Solo deja de tener la última palabra.

Fuentes consultadas

• Stack Overflow, "2025 Developer Survey: AI", consultado el 22/07/2026, https://survey.stackoverflow.co/2025/ai
• GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", consultado el 22/07/2026, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
• arXiv, "AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates", consultado el 22/07/2026, https://arxiv.org/abs/2607.04697
• Prisma, "About the shadow database", consultado el 22/07/2026, https://www.prisma.io/docs/orm/prisma-migrate/understanding-prisma-migrate/shadow-database
• Atlas, "Migration Analyzers", consultado el 22/07/2026, https://atlasgo.io/lint/analyzers
• Atlas, "Verifying Migration Safety", consultado el 22/07/2026, https://atlasgo.io/versioned/lint
• Claude Code Docs, "Configure permissions", consultado el 22/07/2026, https://code.claude.com/docs/en/permissions
• OpenAI Developers, "Non-interactive mode", consultado el 22/07/2026, https://learn.chatgpt.com/docs/non-interactive-mode
• AI Incident Database, "Incident 1152", consultado el 22/07/2026, https://incidentdatabase.ai/cite/1152/
• The Register, "Vibe coding service Replit deleted user's production database, faked data, told fibs galore", consultado el 22/07/2026, https://www.theregister.com/software/2025/07/21/vibe-coding-service-replit-deleted-production-database/719783