La era de simplemente preguntarle al LLM? nos ha hecho increíblemente productivos, pero también peligrosamente cómodos. Actualmente estamos viendo un cambio en el que los desarrolladores están delegando decisiones críticas de infraestructura a modelos generativos. Mientras que usar IA para sugerir un componente de React o un patrón de regex es relativamente de bajo riesgo, dejar que defina las transiciones del esquema de tu base de datos es jugar con fuego.

El problema no es que la IA sea ?mala? con SQL; es que carece de contexto. No conoce tus patrones de tráfico, no entiende tus mecanismos de bloqueo y, desde luego, no le importa si tu entorno de producción se cae a las 3:00 a. m. por un bloqueo de tabla que duró diez minutos más de lo debido.

La ilusión de "funciona"

Cuando le pides a una IA que genere una migración ?por ejemplo, agregar una columna no nula con un valor por defecto a una tabla con cinco millones de filas?, el código que obtienes probablemente será sintácticamente perfecto. Lo ejecutas en tu entorno local con cincuenta filas de datos de prueba y termina en milisegundos.

El problema aparece cuando ese mismo script llega a un entorno de producción.

Antes (estándar generado por IA):

-- Generado por IA: simple, limpio y potencialmente catastrófico
ALTER TABLE orders ADD COLUMN status_code VARCHAR(255) NOT NULL DEFAULT "pending";

En una tabla grande, esta operación puede provocar una reescritura completa de la tabla. En PostgreSQL, por ejemplo, versiones anteriores a la 11 bloqueaban toda la tabla mientras se escribía ese valor por defecto en cada fila. Si tu aplicación maneja alto tráfico, tu API puede empezar a devolver errores 504 (Gateway Timeout), ya que todas las conexiones quedan esperando a que se libere ese bloqueo.

Después (migración segura diseñada por humanos):

-- Paso 1: Agregar la columna como nullable (operación instantánea)
ALTER TABLE orders ADD COLUMN status_code VARCHAR(255);

-- Paso 2: Definir el valor por defecto para nuevas filas
ALTER TABLE orders ALTER COLUMN status_code SET DEFAULT "pending";

-- Paso 3: Actualizar filas existentes en pequeños lotes para evitar bloqueos largos
-- (Esto normalmente se maneja con un job en segundo plano o un script)

-- Paso 4: Agregar la restricción NOT NULL después de poblar los datos
ALTER TABLE orders ALTER COLUMN status_code SET NOT NULL;

Este enfoque divide el cambio en pasos controlados, reduciendo el impacto en producción y evitando bloqueos prolongados que pueden afectar la disponibilidad del sistema.

Cuando la ?comodidad? cuesta millones

No hay que ir muy lejos para encontrar casos donde migraciones automatizadas o mal planificadas han causado verdaderos desastres. Uno de los ejemplos más conocidos de caída por una migración fue la interrupción de GitLab en 2017. Aunque fue un error humano durante una intervención manual, dejó en evidencia lo frágil que puede ser el estado de una base de datos.

Más recientemente, varias startups tecnológicas han reportado corrupción de datos ?silenciosa? cuando migraciones generadas por IA sugirieron cambios en tipos de columnas (como pasar de INT a BIGINT) sin considerar cómo el ORM manejaría la transición durante un despliegue progresivo. Si una migración escrita por IA elimina una columna antes de que la nueva versión del código esté completamente desplegada en todos los nodos, el resultado final puede ser una cadena de errores 500 en la aplicación.

La brecha de contexto

Los modelos de IA trabajan con patrones, no con perfiles de rendimiento. No tienen en cuenta aspectos como:

• Jerarquía de bloqueos: ¿Este ALTER TABLE bloqueará consultas SELECT?

• Retraso en replicación: ¿Esta actualización masiva afectará a las réplicas de lectura?

• Estrategia de despliegue: ¿Se está usando un despliegue blue-green o un reinicio progresivo?

Una migración no es solo un script; es el puente entre dos estados de un sistema en funcionamiento.