Introducción
En septiembre de 2025, el equipo de ingeniería de Anthropic publicó un dato que debería haber reordenado las prioridades de cualquier plataforma de CI: el volumen de jobs en sus pipelines creció 25x en seis meses, y sus ingenieros entregan hoy 8x más código por trimestre que entre 2021 y 2025. La respuesta que implementaron —test impact analysis para ejecutar solo los tests afectados por un cambio— redujo tiempos, pero no tocó el problema estructural. Una semana después, Linear publicó un post titulado «AI coding has made CI a bottleneck»: su suite de tests casi cuadruplicó desde enero y los agentes ya escriben la mayoría de esos tests. Ambos equipos no venden herramientas de CI. Reportan lo que les pasó a sus propios pipelines, y eso le da peso al diagnóstico.
El punto que ambos eluden es más incómodo: acelerar el pipeline no cambia qué verifica. Un agente que abre un PR, espera 20 minutos por un check verde y recibe un fallo, perdió todo su contexto de trabajo. Pero aun si ese check bajara a 40 segundos, sigue evaluando un repositorio con mocks, no el sistema distribuido de 40 servicios donde ese código tiene que convivir con timeouts, colas de mensajes y contratos de API reales. La velocidad del gate no redefine la pregunta que ese gate responde.
Qué ocurrió
Tres publicaciones de septiembre de 2025 convergen en un mismo síntoma con diagnósticos parciales. Anthropic resolvió el volumen con selección inteligente de tests. Linear reestructuró el pipeline end-to-end porque los agentes generan la mayoría de sus tests y el throughput se disparó. Depot, desde la vereda del proveedor de CI, afirmó que el futuro es «dar a los agentes una forma de validar código y mantener confianza mientras trabajan». Los tres identifican que el modelo clásico —un desarrollador humano abre dos o tres PRs por semana y tolera 20 minutos de build— se rompió. Lo que ninguno de los dos primeros explicita es que el modelo clásico tampoco verificaba sistemas distribuidos: verificaba repositorios.
Blacksmith, proveedor de runners de CI, reporta un crecimiento sostenido del 5% al 10% semanal en jobs ejecutados, lo que confirma que el fenómeno no es exclusivo de Anthropic ni de Linear. Cursor, por su parte, reveló en febrero que más del 30% de los PRs que mergea provienen de agentes ejecutando en sandboxes de nube con VMs dedicadas. GitHub Copilot cloud agent corre tests en entornos efímeros respaldados por GitHub Actions; Codex ejecuta un setup script y reanuda contenedores cacheados; Devin arranca desde blueprints de entorno; Greptile con TREX levanta la rama y adjunta logs y screenshots al PR. Todos cierran el loop, pero cierran sobre la misma copia del código.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
DORA (DevOps Research and Assessment) documentó una correlación directa que incomoda: mayor adopción de IA se asocia con aumentos simultáneos en throughput de entrega y en inestabilidad del software. Más código, misma verificación, más rotura. Para equipos de plataforma que operan Kubernetes con 30, 40 o más microservicios, esto traduce a un problema concreto: un campo renombrado en una respuesta JSON que un consumidor downstream todavía lee; un timeout reducido en un servicio que dispara cascadas de retries en otro; un cambio de esquema que funciona contra el fixture de test y bloquea una tabla en staging. Ninguno de esos fallos cruza el pipeline de CI porque ninguno vive dentro del repositorio.
La superficie de riesgo se amplifica con Rust en servicios de alto rendimiento. Un cambio en la serialización de un struct con #[serde(rename)] que pasa todos los tests unitarios del crate puede romper el contrato de un consumer en Go que deserializa con json.Unmarshal esperando el nombre original. El test del crate Rust no importa el consumer Go; el pipeline de CI no levanta el consumer Go. El fallo aparece en producción o en staging, donde ya no hay un agente que repare el contexto en segundos. Para equipos de seguridad, la ausencia de verificación a nivel de sistema también significa que cambios en autenticación, mTLS o políticas de NetworkPolicy de Kubernetes se validan contra mocks, no contra la malla de servicios real.
Detalles técnicos
El problema de placement es estructural, no de rendimiento. CI se ejecuta después de que el PR existe. El agente escribe código, abre el PR y espera. En un sistema distribuido, la verificación relevante ocurre en las costuras: entre servicios, en la cola de mensajes, en la base de datos con datos de forma productiva. Los sandboxes de agentes actuales —GitHub Actions ephemeral environments, contenedores cacheados de Codex, blueprints de Devin— contienen el repo, la rama y lo que el setup script instale. No incluyen los otros 39 servicios, la cola real ni la base de datos con volumen de staging.
La alternativa viable existe y el modelo es conocido: multiplexar. Un cluster de Kubernetes corre una versión estable compartida de todos los servicios y encima despliega entornos de test livianos. Cada entorno despliega únicamente el servicio modificado. Las requests etiquetadas con el header del entorno (por ejemplo, x-test-env: agent-742) atraviesan el servicio modificado y todos los demás saltos resuelven contra las versiones estables compartidas. El servicio modificado habla con dependencias reales que no saben que algo cambió. Un entorno de test cuesta aproximadamente un pod y levanta en segundos. Cincuenta agentes en paralelo comparten un entorno estable en lugar de clonarlo 50 veces.
En términos de orquestación, esto implica un controlador en Kubernetes que recibe un evento de «desplegar entorno efímero», inyecta el pod con la imagen del branch, configura el routing por header (vía Istio VirtualService o un Envoy sidecar con match por header), y expone un endpoint de verificación. El agente invoca ese endpoint como una skill o hook dentro de su loop, no como un paso post-merge.
# Ejemplo simplificado de VirtualService Istio para routing por entorno
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: payments-svc-ephemeral
namespace: test-env-742
spec:
hosts:
– payments-svc
http:
– match:
– headers:
x-test-env:
exact: agent-742
route:
– destination:
host: payments-svc
subset: branch-3a8f2c # imagen del branch del agente
– route:
– destination:
host: payments-svc
subset: stable # versión compartida
Qué deberían hacer los administradores y equipos técnicos
Primero, medir la brecha real. Ejecutar gh run list –json name,conclusion,startedAt,completedAt | jq ‘group_by(.conclusion) | map({status: .[0].conclusion, count: length})’ sobre los últimos 30 días de GitHub Actions y cruzar con la frecuencia de rollbacks en staging. Si el ratio de PRs que pasan CI pero fallan en staging supera el 15%, el pipeline verifica el objeto equivocado.
Segundo, construir un entorno de verificación a nivel de sistema sobre el cluster de Kubernetes existente. No requiere nueva infraestructura: se despliega un namespace con la versión estable de todos los servicios, un controlador de entornos efímeros (un operator con un CRD tipo TestEnvironment), y una capa de routing por header. El equipo de plataforma define una vez la secuencia de verificación —enviar request, capturar log, assertar contrato— y la expone como skill invocable desde Claude Code, Cursor o el agente que use el equipo.
Tercero, gobernar el acceso. Los agentes no pueden tener permisos de admin en el cluster compartido. Aplicar RBAC con Role y RoleBinding restringidos al namespace del entorno efímero, y usar NetworkPolicy para que un entorno no pueda escribir en bases de datos compartidas. Los logs y artefactos de cada verificación deben persistir como registro auditable: qué requests se enviaron, qué servicios se tocaron, qué contratos se cumplieron.
Cuarto, redefinir el rol de CI. Una vez que el agente verifica contra el sistema antes de abrir el PR, CI deja de ser el único gate. Pasa a confirmar lo que ya se validó y a cubrir casos que el entorno efímero no alcanza (tests de carga, compliance de red, escaneo de dependencias con cargo audit para Rust o trivy para contenedores). El pipeline no desaparece; cambia de pregunta.
Conclusión
Anthropic, Linear y GitHub no tienen un problema de velocidad de pipeline. Tienen un problema de alcance de verificación en un mundo donde los agentes generan código a una cadencia que ningún humano sostiene y donde el código vive en sistemas distribuidos de 40 servicios, no en repositorios aislados. Acelerar el gate no redefine qué pregunta responde ese gate. El siguiente paso concreto para equipos de plataforma es dejar de optimizar el tiempo de build y empezar a desplegar entornos efímeros multiplexados sobre Kubernetes que permitan al agente verificar su cambio contra los servicios reales antes de que exista un PR. El loop se cierra, pero cierra sobre el sistema.
Fuentes
- https://thenewstack.io/ci-bottleneck-agent-verification/
- https://www.backblaze.com/blog/
- https://prometheus.io/blog/