La integración continua (CI) se ha convertido en un nuevo punto de estrangulamiento a medida que se amplía el uso de agentes de programación. Esta conclusión se basa en experiencias presentadas por equipos de ingeniería de Anthropic, Linear y Depot durante septiembre, no en el anuncio de una sola herramienta. El volumen de trabajos de CI de Anthropic aumentó 25 veces en seis meses, mientras que sus ingenieros empezaron a enviar por trimestre un volumen de código aproximadamente ocho veces superior al que enviaban entre 2021 y 2025. En Linear, el tamaño del conjunto de pruebas se acercó a cuadruplicar su nivel desde enero, mientras que los agentes ya escriben la mayoría de las pruebas.
Anthropic respondió utilizando el análisis del impacto de las pruebas para ejecutar únicamente las pruebas que probablemente se vean afectadas por el cambio, y Linear rediseñó casi por completo su canalización. Estas medidas reducen el tiempo de espera, pero abordan una sola capa del problema: la velocidad de comprobación del repositorio.
¿Por qué la velocidad de CI ya no es suficiente?
La CI se diseñó históricamente según un patrón de trabajo humano: el desarrollador abre un número limitado de solicitudes de incorporación de cambios cada semana y luego espera el resultado de la canalización mientras pasa a otra tarea. En cambio, un agente puede crear el código, las pruebas y las solicitudes de incorporación de cambios en paralelo, lo que multiplica el número de operaciones de CI. El artículo señala que Blacksmith, una empresa que vende ejecutores de CI, observó un crecimiento semanal de entre el 5% y el 10% en el número de trabajos que ejecuta.
El segundo problema es el momento de la validación. El agente escribe el cambio y luego espera el resultado después de crear la solicitud de incorporación de cambios. Cuando el resultado llega al cabo de 20 minutos, puede haber perdido el contexto de la tarea, mientras que cada problema implica otro ciclo de espera.
El repositorio no es el sistema
En las aplicaciones independientes, las pruebas del repositorio pueden ofrecer una imagen cercana al comportamiento del sistema. Pero en un entorno nativo de la nube, el repositorio representa un solo servicio dentro de un ecosistema que puede incluir decenas de servicios, mientras que el resto del sistema suele representarse mediante interfaces simuladas o datos de prueba.
Por ello, un cambio puede superar las pruebas unitarias, pasar por la CI y funcionar dentro de un entorno aislado, para luego fallar ante la primera solicitud real que atraviese los límites entre servicios. Entre los ejemplos se incluyen cambiar el nombre de un campo del que depende otro servicio, reducir un tiempo de espera y provocar una cadena de reintentos, modificar un esquema y causar el bloqueo de una tabla en el entorno de pruebas, o un punto de conexión que se comporte de forma diferente cuando lo invoca realmente el servicio consumidor.
El artículo cita datos de DevOps Research and Assessment (DORA), que relacionan una mayor adopción de la inteligencia artificial tanto con un aumento de la frecuencia de entrega de software como con una mayor inestabilidad en la entrega. Es decir, producir código más rápido no garantiza una mejor validación.
¿Qué cambia en la práctica?
La solución propuesta no consiste en eliminar la CI ni en ralentizar a los agentes, sino en trasladar parte de la validación a una fase más temprana dentro del ciclo de trabajo del agente, de modo que pruebe el cambio contra el sistema real y no únicamente contra una versión del repositorio. Herramientas como Cursor utilizan entornos aislados en la nube; más del 30% de las solicitudes de incorporación de cambios que integra Cursor proceden de agentes que trabajan de esta manera. Otras herramientas, entre ellas GitHub Copilot cloud agent, Codex, Devin y Greptile, también ofrecen distintas formas de ejecutar código dentro de entornos temporales.
Sin embargo, estos entornos suelen contener la rama, sus configuraciones y lo que pueda instalar el script de configuración, pero no los demás servicios, la cola de mensajes real ni una base de datos similar a la de producción. Por eso, el artículo considera que el ciclo se cierra, pero puede cerrarse alrededor del objeto equivocado.
Entornos compartidos y validación controlada
El artículo propone ejecutar una versión estable compartida de los servicios dentro de un clúster de Kubernetes, creando entornos de prueba ligeros que desplieguen únicamente el servicio modificado. Las solicitudes etiquetadas se dirigen a este servicio, mientras que el resto de las rutas se conecta con las versiones estables compartidas. De este modo, un gran número de agentes puede compartir el entorno en lugar de copiar todo el sistema para cada agente; el artículo estima que el coste del entorno podría acercarse al de un solo contenedor y que su puesta en marcha tardaría segundos, pero la fuente no ofrece mediciones independientes que demuestren estas estimaciones en todos los entornos.
El entorno por sí solo tampoco es suficiente. Los equipos de plataforma necesitan procedimientos aprobados que definan qué solicitudes se envían, qué registros se recopilan y qué contratos deben demostrarse. También deben registrarse los servicios que tocó la prueba y sus resultados, para que el registro pueda ser interpretado por las herramientas de revisión y las puertas de incorporación de cambios. El autor subraya que la gobernanza es necesaria para impedir que los agentes ejecuten acciones inseguras dentro de un clúster compartido.
Desde la perspectiva de certi.news, el cambio real no consiste simplemente en acelerar la CI, sino en redefinir lo que debe significar el «éxito» de la validación. Las pruebas del repositorio siguen siendo importantes, pero por sí solas no bastan para los sistemas distribuidos que los agentes producen con mayor rapidez. Siguen abiertas las cuestiones del coste, el aislamiento, la seguridad de los datos y la medición de la precisión de la validación, y el material presenta una tesis analítica, no un estándar probado ni un producto concreto.