Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic

Puntos clave

1. La cadena causal, no solo la cifra. 8× más código desplegado por ingeniero por trimestre, el 80% escrito por Claude, además de un papel significativo de la IA en la revisión y aprobación de PR; ×10 en el número de tests con plantilla casi constante. Resultado: ×25 en jobs de CI en seis meses. « Escribir código ya no es la restricción, y una vez que la revisión de PR se acelera, la CI empieza a sentir la presión. » El cuello de botella no desaparece, se desplaza un nivel más abajo — una variante infraestructural del "cuello de botella de verificación" de [[sfeir-code-review-anneau-contraintes-2026-07-30]].
2. El argumento específico a los agentes. , el punto más transferible del texto. Ejecutar todo en cada cambio funciona hasta cierto punto, luego las puertas de control se vuelven largas, costosas y poco fiables — y por tanto ignoradas. Sobre todo: un humano sabe descartar un fallo de test que no le concierne, un agente no — necesita más contexto y dirección. Dado un conjunto de tests válido y relevante, se autoverifica e itera por sí mismo. La selección de tests deja de ser una optimización de costes y se convierte en una condición para la autonomía.
3. La arquitectura v0 y su pecado original. mantener un historial por test requería un único escritor, de ahí un único proceso, de ahí ningún sharding horizontal posible. El estado vivía dentro del proceso.
4. La física del retraso. 20 minutos de retraso = decenas de miles de actualizaciones sin aplicar. Tres consecuencias distintas — un mal merge hace fallar un test para todos y desencadena investigaciones innecesarias; una dependencia que empieza a fallar de forma intermitente produce reds que bloquean los merges; un test corregido o añadido no se ejecuta hasta que el listener se ha puesto al día, con riesgo de regresión.
5. Los tres parches y su vida media. (1) duplicar los núcleos — 70 días; (2) sharding por paquete — el listener no necesitaba un único escritor global, sino un único escritor por paquete, y Claude generó el código — 29 días; (3) reinicios diarios — menos de un día, con solo cuatro bugs encontrados, un cambio de asignador de memoria sin efecto, y el rechazo deliberado a perfilar la memoria de un singleton ya bajo carga.
6. La supervisión delegada. , un detalle que vale la pena retener: una sesión de larga duración en una versión interna de Claude Tag dedicada al servicio, que alerta al autor en cuanto el listener se queda más de 50.000 jobs por detrás y retoma la conversación donde la dejó. Durante meses, sin tener que recargar el contexto de los intentos pasados. Y « Claude a menudo defendía una revisión completa, pero normalmente optábamos por otro parche ».
7. La revisión completa. dotar al servicio de una base — un magasin de données en mémoire. Cualquier worker listener procesa cualquier resultado, lo añade a un log y sigue adelante sin conservar nada: stateless, por tanto escalable horizontalmente. Un consumidor separado agrega el log en un historial por test cada pocos segundos. Más caro de ejecutar, pero mucho más fácil de escalar y perfilar que un singleton frágil. El ajuste fino (tamaño del log, número de workers) lo hizo en gran parte Claude por su cuenta.
8. La economía de la decisión ha cambiado. Tres semanas para un ingeniero, frente a aproximadamente un trimestre un año antes. Ese es el cambio real: las medias medidas compran cada vez menos tiempo mientras que una revisión completa cuesta cada vez menos — « mucho más sostenible ahora que escribir código ya no es el cuello de botella ».
9. Las cuatro reglas que extrae de ello. asumir que la arquitectura se enfrentará a ×25 la carga dentro de dos trimestres, ya sea construida o comprada; aceptar que el over-engineering retrocede como error — apuntar a 10-20× la escala percibida ya desde la v0 si el presupuesto lo permite; instrumentar los servicios para que sirvan de ojos y oídos de Claude, como mínimo el invariante "tantos jobs de CI de salida como de entrada"; sacar el estado del proceso desde el principio, nunca ejecutar un servicio crítico como una instancia única no medible.
10. La forma de la carga cambia, no solo su volumen. Claude favorece PR más pequeñas y granulares (un argumento más contra ejecutar todos los tests en cada PR), el suelo de actividad sube porque los agentes empujan por la noche y los fines de semana, pero la carga sigue siendo a rachas ya que los humanos todavía conducen y aprueban una parte significativa de las PR.
11. La apuesta final. , a verificar en doce meses: « anticipo que la arquitectura de selección de tests escalada horizontalmente se convertirá en estándar de la industria » a medida que los agentes producen tanto más PR como más tests.