El CI se atasca cuando el código lo genera una IA: cómo rediseñar el pipeline

Los agentes de código que funcionan sobre modelos de lenguaje escriben mucho más rápido de lo que un pipeline de integración continua puede validar. Ese desfase tiene nombre —cuello de botella del CI— y una consecuencia práctica: colas de cambios sin revisar, desarrolladores apagando fuegos y regresiones que se cuelan por puro volumen. La propuesta que circula estos días es reorganizar el pipeline en capas que fallen rápido antes de gastar minutos en código roto.

De ritmo humano a ritmo de máquina

Los pipelines se diseñaron alrededor de los límites cognitivos de una persona: alguien escribe una función, la prueba en local y hace push; el CI actúa de red de seguridad. El cuello de botella era la revisión humana. Con un agente autónomo el flujo de entrada cambia: puede generar 5.000 líneas y 50 tests en menos de un minuto. Si la validación tarda quince, hay catorce minutos de espera. Y si el agente trabaja en bucle sin esperar, acumula cambios incompatibles entre sí, conflictos de merge que en realidad son conflictos semánticos en el grafo de dependencias.

A eso se suma que el código generado tiende a ser verboso: duplica lógica porque no reconoce las abstracciones que ya existen, infla la suite con tests de frontera y, lo más molesto, importa librerías o versiones que no están en el lockfile. Cada commit pesa más, las operaciones de git se ralentizan y el runner, que suele ser efímero y con disco justo, sufre sobre todo en E/S.

Fallos que el CI tradicional no sabe leer

Tres modos de fallo se repiten. El primero son los tests inestables. Los modelos son probabilísticos: escriben código que pasa el 90% de las veces y falla por una condición de carrera el otro 10%. Si el agente usa el resultado del CI como señal para corregirse, un test inestable le hace cambiar cosas al azar y arreglar algo rompiendo otra cosa: es el clásico "reward hacking" aplicado a un pipeline. La tubería tiene que distinguir un error real de un fallo transitorio.

El segundo es el infierno de dependencias. Un modelo sugiere paquetes vistos en su entrenamiento, a veces obsoletos o vulnerables, y dos agentes distintos pueden meter lodash en un fichero y underscore en otro. Cuando npm install tarda minutos, validar la integridad del grafo antes de instalar sale más barato que instalar y esperar.

El tercero es seguridad. El código generado cuela secretos embebidos o APIs obsoletas. Con este volumen, el escaneo tiene que ser la primera puerta y no la última: si rechazas en treinta segundos, no gastes diez minutos de build.

Validación por capas

La receta que plantea el análisis es jerárquica, con tres niveles:

• Capa 1, pre-commit o en el propio agente, milisegundos: linters y formateadores, comprobación del grafo de imports sin instalar nada y escaneo de secretos con Gitleaks o TruffleHog.
• Capa 2, arranque rápido en CI, segundos o minutos: solo los tests afectados por el commit, chequeo de tipos con tsc --noEmit o MyPy, y auditoría de dependencias. El chequeo de tipos es el mejor antídoto contra firmas de API inventadas.
• Capa 3, validación completa, minutos u horas: suite entera, generación de artefactos, benchmarks de rendimiento y despliegue a staging con smoke tests.

Queda por resolver la segunda pata: ejecutar los tests de forma determinista y aislar la inestabilidad. Ahí el texto se queda, y no hay cifras públicas de cuánto se recorta el tiempo de ciclo. Lo que sí es trasladable a cualquier equipo es el orden: lo barato primero. Un pipeline pensado para un humano que teclea no aguanta que el que teclea sea un modelo.