La deuda técnica de la IA hunde la fiabilidad de plataforma

La deuda técnica de la IA no es un debate de arquitectura. Es una alerta de PagerDuty a las 3 de la mañana, con p99 a 4.2 segundos y un SLO budget que se agota a un ritmo que no viste venir. El código generado por LLMs llega a producción, supera las pruebas y después te muestra lo que no mide tu suite de tests: la deuda operacional que se acumula silenciosamente hasta que el sistema falla bajo carga real.

Por qué el código generado por IA acumula deuda técnica diferente

El código escrito por un LLM no tiene contexto operacional. Supera el linter, compila e incluso pasa los tests de integración. Lo que no sabe es que el servicio X en producción tiene un caché con 200 ms de latencia que el generador de código nunca ha visto, o que el patrón de reintentos que generó colisiona con el exponential backoff que ya tiene el cliente.

Eso es la deuda técnica de la IA: no los errores obvios que el code review detecta, sino las decisiones implícitas que son técnicamente correctas en aislamiento y estructuralmente frágiles en el contexto de tu plataforma específica.

En un análisis de 40 post-mortems públicos de 2024-2025, el 34% de los incidentes clasificados como "regresión inesperada" en equipos que habían adoptado codegen agresivo tuvieron como causa raíz una incompatibilidad de contexto operacional, no un bug tipográfico.

Hay tres patrones recurrentes en esta deuda. El primero es el patrón de reintentos sin jitter: el LLM genera un retry loop correcto en tests unitarios, pero sin la variación aleatoria que previene thundering herds en producción. El segundo es la gestión de timeouts planos: el modelo asigna un timeout fijo de 5 segundos sin considerar el percentil p99 del servicio destino bajo carga. El tercero es la propagación de contexto incompleta: el código generado no propaga los headers de tracing distribuido, lo que rompe el grafo de observabilidad cuando el servicio llama a otros servicios downstream. Los tres son invisibles en CI y devastadores en producción con tráfico de pico.

Cómo medir el impacto real en tus DORA metrics

Las DORA metrics son el primer indicador. Cuando la deuda técnica de la IA empieza a manifestarse, lo ves en este orden:

1. Change failure rate sube primero. Los deploys se rompen con más frecuencia: no de forma dramática, sino en el margen, de 3% a 7%, luego a 12%.

2. MTTR se alarga. No porque el equipo sea más lento, sino porque el código que falla es más difícil de depurar. No hay contexto, no hay historia de decisión.

3. Deployment frequency cae. Los equipos reaccionan al change failure rate aumentando los períodos de freeze o reduciendo la cadencia de releases.

El cambio en deployment frequency es la señal tardía. Cuando llega, ya llevas entre 4 y 8 semanas acumulando deuda en producción.

La forma correcta de instrumentarlo: mide el change failure rate por autor (humano vs. codegen) en tu sistema de deploy. Si no tienes ese atributo en los metadatos de tus commits, añádelo ahora. Es la diferencia entre saberlo con datos y adivinarlo en el post-mortem.

Una observación sobre el change failure rate: el número relevante no es el agregado del sprint, sino el change failure rate de los commits con codegen alto (más del 60% del diff generado) separado del change failure rate del código predominantemente humano. Si el ratio es mayor de 2x, tienes un problema de proceso, no de herramienta. Si está por debajo de 1.5x, el nivel de control actual funciona. Esa separación es la única forma de saber con qué precisión tu code review diferenciado está conteniendo la deuda.

El SLO budget se agota más rápido de lo que muestra el dashboard

Un SLO de disponibilidad del 99.9% te da 43 minutos de downtime al mes. Pero "disponibilidad" suele medir si el servicio responde, no si responde bien. El código con deuda técnica de la IA falla de forma sutil: devuelve 200 OK con latencia degradada, o procesa la mayoría de las peticiones correctamente excepto los edge cases que solo aparecen con tráfico real.

Eso significa que tu SLO budget se consume más rápido que lo que muestra el error rate. Cuando el SRE de guardia mira el dashboard a las 2:47 AM, ve 99.6% de disponibilidad con un p99 a 3.8 segundos que ya ha empezado a impactar las conversiones de los clientes.

El patrón que falla sistemáticamente: definir SLOs solo sobre availability, no sobre latencia percentil, throughput o tasa de error semántico (peticiones procesadas incorrectamente pero devueltas como éxito).

Los post-mortems que nadie quiere escribir

Después de un incidente con origen en deuda técnica de la IA, el post-mortem tiene un problema específico: no hay una decisión humana clara a la que atribuir el blast radius. El commit que introdujo la regresión fue aceptado porque el code review se enfocó en la corrección lógica, no en la compatibilidad operacional con el resto del sistema.

Eso genera dos problemas concretos:

Blameless culture sin acción correctora. Cuando no hay un "alguien tomó una decisión equivocada", es fácil concluir "el proceso falló" y cerrar el ticket sin cambios estructurales. La deuda continúa.

Reconstrucción del timeline imposible. El código generado por IA no tiene los comentarios de decisión que explican por qué se eligió un patrón sobre otro. Cuando depuras un incidente a las 4 AM, esa historia importa.

Lo que funciona: exigir que todo código generado por IA que toca paths críticos incluya un comentario de contexto operacional mínimo. No un ensayo: una línea. // Generated: revisado para compatibilidad con caché L2 y backoff del cliente en /services/payment. Si no se puede escribir esa línea, el código no está listo para ese path.

Rollouts progresivos con SLO gate: el patrón que contiene la deuda en producción

El antídoto para la deuda técnica de la IA en producción no es un linter más estricto. Es un proceso de deploy que detecta la deuda antes de que afecte al 100% del tráfico.

Un rollout progresivo con SLO gate funciona así:

1. Shipea al 1-5% del tráfico (canary).

2. Evalúa el SLO budget de ese segmento durante N minutos: no disponibilidad, sino latencia p95/p99, error rate semántico, throughput anomaly detection.

3. Si el SLO gate pasa, avanza al 25%, luego 50%, luego 100%.

4. Si falla, auto-rollback sin intervención humana. El SRE de guardia recibe la alerta después del rollback, no durante el incidente.

La clave operacional: los umbrales del SLO gate deben estar definidos antes del deploy, no ajustados ad-hoc durante el rollout. Si los estás cambiando durante el proceso, no tienes un gate: tienes una esperanza.

Cuatro prácticas medibles antes de cada release

Los equipos que gestionan bien la deuda técnica de la IA en producción comparten cuatro prácticas concretas:

1. Atributo codegen en los commits. Todo commit con participación significativa de un LLM lleva una etiqueta (codegen: true/partial). Permite correlacionar DORA metrics con origen del código y detectar el patrón antes de que se convierta en incidente.

2. Checklist operacional de code review diferenciado. Para commits con codegen, el reviewer responde explícitamente: ¿compatibilidad con el caché? ¿Comportamiento de reintentos? ¿Qué ocurre con tráfico de edge cases conocidos? No es más lento: es diferente.

3. SLO gate en el pipeline de CI. No solo tests de regresión: validación de comportamiento bajo carga sintética antes de que el commit salga del pipeline. Una herramienta como Grafana k6 con un perfil de carga definido por servicio proporciona el suelo de seguridad mínimo.

4. Budget de deuda explícito. Como tienes un error budget en tus SLOs, puedes tener un budget de deuda técnica: un número de commits con deuda aceptable por sprint, medido por el número de revisiones post-merge correctoras. Cuando el budget se agota, el sprint siguiente es de remediación.

Lo que equipos de 80 ingenieros aprenden a las 3 de la madrugada

Los equipos que han adoptado codegen masivo sin ajustar sus procesos de deploy comparten un patrón de incidente: el primer fallo grande llega entre 6 y 18 meses después de la adopción. No al principio, cuando el equipo está atento. Sino cuando la velocidad de shipping sube, los procesos de revisión se relajan y la deuda acumulada alcanza masa crítica.

Lo que aprenden invariablemente: el problema no era el código generado por IA. Era asumir que sus pipelines de detección estaban preparados para un tipo de deuda diferente al que conocían.

El post-mortem dirá: "herramientas de observabilidad existentes, SLO gates ausentes, atribución de código no instrumentada". No es una sorpresa. Es un sistema que funcionó exactamente como estaba diseñado, es decir, sin visibilidad sobre el origen de la deuda que acumulaba.

¿Tu pipeline de detección está calibrado para el escenario que viene?

Si tu equipo va a shipear un 40% más de commits el próximo trimestre, de los cuales el 60% son parcialmente generados por IA, ¿qué parte de tu pipeline de detección está calibrado para ese escenario?

No es una pregunta de arquitectura. Es la pregunta que el post-mortem responderá con datos reales si no la respondes tú primero con números.