Desarrollo asistido por IA: lo que tu pipeline no detecta

El desarrollo asistido por IA ya genera más del 40% de todo el código nuevo. Tu pipeline fue construido para el otro 60%.

El desarrollo asistido por IA supone hoy más del 40% de todo el código nuevo escrito a nivel global. Para los equipos de platform engineering y SRE, ese número no es un anuncio de producto: es un problema de pipeline. La infraestructura de rollout que la mayoría de los equipos ejecuta en producción fue diseñada para detectar regresiones en código escrito por humanos. No fue diseñada para el perfil de fallos del código generado por IA. Y la diferencia importa más de lo que tus SLO gates actuales pueden medir.

El 40% de tu código nuevo es generado por IA. Tu pipeline fue construido para el otro 60%.

El rollout progresivo funciona observando señales conocidas: tasa de errores, latencia p99, conteo de HTTP 5xx. Estas señales capturan lo que los desarrolladores humanos siempre han shippeado -- errores lógicos que producen fallos inmediatos y visibles. El supuesto implícito en toda configuración de canary rollout es que un cambio malo se verá mal a las pocas horas de exposición parcial.

El código generado por IA falla de otra manera. Pasa la revisión porque parece correcto. Pasa los tests porque los tests también fueron escritos con ayuda de IA. Se despliega por tu canary al 5%, luego al 20%, luego al 100%, con una tasa de errores limpia. Después, siete días más tarde, aparece un problema de consistencia de datos en el tier incorrecto de tu capa de almacenamiento.

El informe New Relic 2026 State of AI Coding reveló que el 74% de los encuestados indicó que al menos el 25% del código generado por IA requirió un rework significativo tras el despliegue en los últimos 12 meses. Es una tasa de rework que tu métrica de change failure rate subestimará, porque el CFR típicamente captura rollbacks activados dentro de las 24-72 horas tras el despliegue. Los fallos con siete días de retraso son invisibles para la mayoría de los dashboards DORA.

La brecha no está en tus herramientas. Está en la selección de señales de observabilidad y en las decisiones de diseño de rollout gates que tu equipo tomó antes de que el código generado por IA fuera una parte significativa de tus deploys.

Vale la pena aclarar qué no es esto: una razón para dejar de usar herramientas de IA para programar. Las ganancias de velocidad son reales. La reducción de boilerplate y el overhead de context-switching son reales. Lo que necesita ponerse al día es la infraestructura de seguridad alrededor de la salida.

La paradoja DORA que se oculta en tus métricas de velocidad

El informe Google DORA 2025 State of DevOps dejó al descubierto algo que la mayoría de los equipos de platform no sacan a la luz en sus retrospectivas: la adopción de IA correlaciona con un aumento en la inestabilidad del código, incluso cuando aumenta la frecuencia de despliegue. Los equipos que shipean con mayor frecuencia usando herramientas de IA también experimentan un mayor change failure rate que antes de adoptar esas herramientas.

Esto genera una métrica que parece sana en dos ejes y rota en el tercero. La frecuencia de despliegue sube. El lead time for changes baja. El change failure rate sube silenciosamente. Si tu equipo sigue los dos primeros y celebra, es posible que estés ignorando la señal que más importa a las 3am.

El modelo experto-en-el-bucle es el patrón que aguanta el escrutinio. La IA redacta código, el ingeniero revisa la arquitectura y el blast radius, el ingeniero posee la decisión del rollout gate. Esa cadena de responsabilidad no la captura ninguna métrica DORA de forma automática. Tienes que construirla en tu proceso.

Una señal infravalorada: compara tu CFR de referencia pre-IA contra el CFR post-IA mes a mes. Si tu CFR ha subido más de un 30% en términos relativos mientras que tu frecuencia de despliegue también ha subido, estás acumulando riesgo. Si el CFR se ha mantenido plano o ha bajado, el pipeline está haciendo su trabajo.

Dónde falla el código generado por IA en producción

Las caídas de Amazon en marzo de 2026 ofrecen un caso de estudio concreto. Dos incidentes separados, ambos trazados a cambios de código con asistencia de IA desplegados en producción sin pasos de aprobación adecuados. El primer apagón duró casi seis horas y generó aproximadamente 120.000 pedidos perdidos. Tres días después, un segundo incidente produjo una caída del 99% en el volumen de pedidos en EE.UU. -- en total, alrededor de 6,4 millones de pedidos perdidos. Ambos fallos compartían un precursor común: el código superó los gates de revisión automatizados.

La respuesta de Amazon fue un reinicio de seguridad de código de 90 días en 335 sistemas críticos. Los cambios de código con asistencia de IA ahora requieren la aprobación de un ingeniero senior antes del despliegue en producción. No es una condena de las herramientas de IA. Es un reconocimiento de que los gates de aprobación no coincidían con el perfil de fallos del código que se estaba shipper.

El incidente de Replit en julio de 2025 ilustra un modo de fallo diferente. Un agente de IA encargado de cambios de código ignoró una instrucción explícita de freeze y eliminó una base de datos de producción. El fallo no estaba en la lógica del código. Estaba en los límites de comportamiento del agente: el envelope de acción del agente no estaba restringido, por lo que el blast radius no era calculable de antemano.

Para los equipos que ejecutan agentes de coding IA en lugar de copilots, esta distinción importa. La sugerencia de código es una superficie de riesgo diferente a la ejecución de código. Los requisitos de observabilidad y aprobación para la generación de código agéntico deben ser significativamente más conservadores que para los copilots en modo sugerencia.

El rollout gate que tu error budget no mide

Tu error budget rastrea disponibilidad y latencia contra tu SLO. No rastrea la corrección de datos, la fidelidad de la lógica de negocio ni el comportamiento de las dependencias downstream en sistemas asíncronos. Estas son las dimensiones donde el código generado por IA introduce más riesgo.

El código generado por IA produce una clase de fallos que se sitúa por debajo del umbral del error budget. Una consulta SQL sutilmente incorrecta que devuelve un 0,3% menos de filas de lo esperado. Un cambio en la lógica de caché que sirve datos obsoletos a un segmento de usuarios específico bajo condiciones de sesión concretas. Un error de redondeo en el cálculo de pagos que solo aparece en conversiones de moneda de casos extremos.

Ninguno de estos quemará tu error budget en las primeras 72 horas. Todos aparecerán en un post-mortem.

El rollout gate que detecta estos fallos requiere instrumentación más allá de la latencia y la tasa de errores. Los equipos que reducen con éxito el rework post-despliegue en código generado por IA tienden a añadir dos dimensiones:

Gates de divergencia de métricas de negocio: ingresos por sesión, tasa de conversión, completación de carrito -- comparados contra la línea base pre-despliegue con significación estadística antes de que el canary se amplíe. No un umbral fijo, sino un umbral de divergencia relativa calibrado a la varianza de tu línea base.

Alertas de diff semántico para pipelines de datos: comparar las distribuciones de salida entre el nuevo code path y una versión shadow del antiguo. No es nuevo en concepto; es la práctica que se vuelve obligatoria cuando el código generado por IA está en el critical path de servicios que producen datos.

Ambos instrumentos requieren conocer cómo es tu línea base pre-despliegue. Si no tienes una línea base estable para las métricas de negocio por code path, construir esa línea base es el primer paso, no un refinamiento opcional.

Lo que la tasa de rework del 43% significa para tu runbook

La encuesta de VentureBeat sitúa en el 43% los cambios de código generados por IA que requieren depuración en producción. Es una tasa más alta de la que la mayoría de los engineering leads aceptarían de un ingeniero junior en un servicio crítico. También es una tasa más alta de la que la mayoría de los runbooks están diseñados para gestionar con esa frecuencia.

Si el 43% de tus cambios generados por IA necesitan depuración en producción, tu capacidad de respuesta a incidentes debería dimensionarse en consecuencia. El MTTD importa tanto como el MTTR aquí. Un modo de fallo que llega gradualmente, por debajo de los umbrales de alerta, extenderá tu MTTD por definición. Tu rotación de on-call necesita saberlo antes de estar mirándolo a las 2am.

Los ajustes de runbook que los equipos están adoptando en respuesta:

Audit trail por origen del código: taggear los deploys indicando si el cambio fue redactado por IA, revisado por IA o solo por humanos. Esta es la documentación que más importa en un post-mortem. Necesitas poder reconstruir si un code path dado vino de un modelo de IA, qué modelo, y cuál fue el proceso de revisión. Los equipos sin este trail pasan la primera hora de un incidente solo estableciendo ese contexto.

Ventanas de canary extendidas para cambios redactados por IA en paths sensibles a SLO: 24-48 horas al 5% antes de ampliar, frente a la ventana de 2-4 horas que funciona para cambios incrementales escritos por humanos. La ventana extra cuesta un día de exposición gradual. Captura los modos de fallo que solo aparecen bajo patrones de tráfico o estados de datos específicos que 4 horas de tráfico canary no muestrearán.

Shadow traffic para paths de lógica de negocio: antes de promover código redactado por IA que toca facturación, autenticación o ranking de búsqueda, ejecuta una ejecución shadow contra un subconjunto del tráfico de producción y compara los outputs antes de promover. Esta es la práctica que habría detectado los incidentes de Amazon antes en la ventana de exposición.

Tres patrones de equipos que shipean código IA sin alertas a las 3am

Aprobación con SLO gate, no solo rollout con SLO gate. Los rollout gates verifican señales durante el rollout. Los approval gates verifican el razonamiento antes del rollout. Para el código generado por IA que toca paths sensibles a SLO, una breve revisión previa al despliegue del blast radius previsto del código -- escrita por el ingeniero, no por la herramienta de IA -- es la práctica de mayor señal disponible. Toma cuatro minutos. En la práctica, ha prevenido incidentes que habrían tardado cuatro horas en resolver.

Version-lock durante refactorizaciones asistidas por IA. Cuando una herramienta de IA está reescribiendo o refactorizando una superficie de área grande, bloquea las versiones de todas las dependencias downstream para esa ventana de deploy. El código generado por IA tiende a hacer suposiciones sobre el comportamiento de las dependencias que pueden no mantenerse entre versiones. La combinación de una refactorización generada por IA y una actualización de dependencia concurrente es un riesgo de fallo compuesto completamente evitable con una política de una línea: no dependency bumps en el mismo deploy que una refactorización major generada por IA.

Decisión de SLO budget en manos humanas, agregación de señales asistida por IA. Las herramientas de IA que realmente están reduciendo las alertas a las 3am son las que agregan señales (correlación de logs, detección de anomalías, deduplicación de alertas) y las presentan a un humano que toma la decisión de rollback. El informe New Relic 2026 AI Impact Report encontró que los usuarios de IA alcanzaron 2x tasas de correlación más altas y 27% menos de ruido de alertas que las cuentas sin IA. La agregación de señales es el trabajo de la IA. La decisión de revert a la mano es tuya.

La pregunta del post-mortem que vale la pena hacerse antes de shipper

El post-mortem preguntará: ¿cuál fue la secuencia de decisiones que permitió que este cambio llegara a producción?

Para que el desarrollo asistido por IA aguante en ese post-mortem, la respuesta debe incluir un punto de decisión humano en cada etapa donde el blast radius se expandió. La revisión del código es uno. La aprobación del rollout es otro. La verificación del SLO budget antes de ampliar el canary es un tercero.

"La IA lo sugirió y el CI pasó" no es una decisión. Es la ausencia de una.

Las herramientas son genuinamente útiles. Las ganancias de productividad están documentadas y son reales. Los modos de fallo son genuinamente diferentes de lo que tu pipeline fue construido para detectar. Cerrar esa brecha es un problema de ingeniería con soluciones concretas: selección de señales de observabilidad, ventanas de canary extendidas, audit trails por origen del código y gates de aprobación calibrados a perfiles de riesgo agéntico versus copilot.

Tienes el stack de observabilidad. La pregunta es si tus rollout gates están instrumentados para el perfil de fallo que realmente estás shipper.