En septiembre, tres publicaciones recientes han destacado un problema que debería preocupar a responsables técnicos: el creciente cuello de botella en la integración continua (CI) provocado por el elevado volumen de pruebas generado por agentes de inteligencia artificial que automatizan la escritura de código.
El equipo de ingeniería de Anthropic reveló que el volumen de trabajos de CI en su organización se multiplicó por 25 en apenas seis meses, impulsado por un aumento de casi ocho veces en la cantidad de código desplegado trimestralmente respecto a la etapa 2021-2025. Para mitigar esta explosión, implementaron un sistema de análisis de impacto en las pruebas que ejecuta únicamente los test afectados por los cambios.
Una semana después, Linear compartió cómo su suite de pruebas casi se cuadruplicó desde enero y que la mayoría de las pruebas ahora son redactadas por agentes automatizados. Para seguir el ritmo, rediseñaron su canalización de CI completamente. 
Finalmente, el CEO de Depot indicó que la integración continua está evolucionando hacia un modelo donde los agentes pueden validar el código y mantener la confianza durante su propio desarrollo.
Estos casos no provienen de empresas de herramientas de CI, sino de usuarios avanzados que experimentan directamente el crecimiento exponencial en la generación de tareas de integración continua, algo que justifica una inspección profunda.
La razón del cuello de botella en integración continua
Durante décadas, las plataformas de CI se dimensionaron pensando en la producción humana, donde un desarrollador abría unas pocas solicitudes de extracción semanalmente y una espera de 20 minutos para la prueba era tolerable porque el programador ya estaba inmerso en otra tarea. La introducción de agentes automatizados ha roto este equilibrio por dos motivos clave:
- Volumen: Cuando un mismo técnico opera varios agentes en paralelo, el número de PR se multiplica exponencialmente, no linealmente. Anthropic y Blacksmith evidencian crecimientos semanales de hasta un 10 % en tareas de CI.
- Momento del ciclo: La ejecución de CI se efectúa tras abrir el PR, lo que significa que un agente que espera resultados pierde el contexto operativo durante la espera. Así, la velocidad de ejecución del agente no se ve reflejada en la agilidad global debido a un ciclo de validación externo lento.
Como respuesta, la industria ha intentado acelerar la CI con mejores runners, selección inteligente de pruebas y cachés más grandes, acortando las canalizaciones incluso antes de que se realice el commit. Sin embargo, estas mejoras se limitan a verificar el repositorio y no el sistema global.
¿Qué no refleja una canalización exitosa?
Para aplicaciones aisladas, el repositorio es el propio sistema, y pasar los tests indica alto nivel de confianza. Pero para sistemas distribuidos en la nube, un repositorio representa sólo un servicio entre decenas. Las pruebas unitarias se ejecutan simulando dependencias y no garantizan que los cambios funcionen correctamente en interacción real con otras partes del sistema.
Los errores más dañinos en estos sistemas residen en la integración: cambios en campos de respuesta, timeouts, esquemas de bases de datos o comportamientos de endpoints que inciden en servicios downstream. La CI, incluso la rápida, no detecta estas fallas porque sólo revisa el código aislado.
Es decir, el problema no es que la CI sea lenta, sino que sigue verificando una pregunta equivocada, que pasa de una evaluación humana a un control automatizado sin cambiar su enfoque.
El problema: código más rápido, misma verificación, más fallos
Un informe de DevOps Research and Assessment (DORA) confirma que una mayor adopción de IA incrementa tanto la velocidad de entrega como la inestabilidad del software. Por tanto, acelerar la CI es insuficiente si no cambia el ámbito de la verificación.
La verificación debe integrarse en el ciclo del agente
Empresas como Cursor han demostrado que los agentes deben tener la capacidad de ejecutar y probar el código que generan en entornos en la nube antes de abrir un PR, ya que sin esta capacidad se alcanza un límite en la autonomía de los agentes.
Sin embargo, estos entornos contienen sólo el repositorio y los servicios instalados localmente, sin el ecosistema completo de los demás servicios, colas de mensajes o bases de datos realistas. Así, el ciclo de verificación se cierra, pero sobre una representación incompleta.
Por ello, la verificación previa a la solicitud de extracción para sistemas distribuidos debe centrarse en el sistema global, no sólo en un repositorio aislado.
Multiplexar en lugar de clonar: cómo hacerlo costeable
Un argumento común en contra de este modelo es el costo, pues si cada agente necesita un entorno completo, los recursos necesarios serían prohibitivos.
La solución consiste en multiplexar, es decir, compartir un entorno estable de servicios desplegados en un clúster centralizado (como Kubernetes) sobre el que se montan múltiples entornos de prueba ligeros que incluyen sólo el servicio modificado. Las peticiones se enrutan para usar el servicio alterado, mientras que el resto de servicios usados son versiones estables compartidas.
Esta arquitectura reduce drásticamente los recursos requeridos para realizar pruebas en entornos casi reales, permitiendo que decenas de agentes usen un entorno común y se levanten en segundos.
La gobernanza es clave para verificar con agentes
No basta con disponer de entornos baratos y rápidos, los agentes también requieren un modelo estructurado para usarlos, enviando solicitudes, capturando logs, verificando contratos y reportando resultados de forma estandarizada.
El modelo eficiente es que el equipo de plataforma defina estas acciones autorizadas y controladas, que los agentes simplemente ejecutan como parte de sus ciclos de trabajo. De este modo, se asegura que las validaciones sean comparables y seguras dentro de un clúster compartido.
Además, los resultados quedan registrados en forma de artefactos inteligentes que pueden ser reutilizados por herramientas de revisión y validación, permitiendo que la integración continua se transforme en un paso de confirmación más que en el primer lugar donde detectan problemas.
El futuro está en la verificación integrada y temprana
Esperamos que los proveedores de herramientas CI continúen mejorando la velocidad y que los agentes de código sigan perfeccionándose para ejecutar el software que generan en entornos controlados. Sin embargo, ninguno de estos avances resolverá la brecha existente si la verificación sigue centrada en el código almacenado y no en el conjunto del sistema.
Las organizaciones que lideren la innovación serán aquellas que integren la validación del código generado por agentes con el sistema en vivo antes de abrir la solicitud de extracción. Esta práctica reduce riesgos y genera mayor confianza en cambios acelerados impulsados por IA.
Para responder a esta necesidad, herramientas como Signadot han desarrollado soluciones que hacen asequible esta verificación gobernada y sistemática en cada cambio realizado por agentes.
