# malhotra-anthropic-ci-test-impact-analysis-2026-09-14

## Veille

Post de ingeniería de **Anthropic** publicado el **14 de septiembre de 2026** en claude.com/blog (~1.400 palabras, cinco secciones), escrito por **Sachin Malhotra**. Relata el escalado del servicio de **test impact analysis** — seleccionar qué tests ejecutar por cada cambio — bajo la presión de la codificación agéntica. Las cifras de entrada y su cadena: los ingenieros despliegan en promedio **8×** más código por trimestre que en 2021-2025, **Claude escribe el 80% de él** y también carga un peso significativo en la revisión y aprobación de PR; el número de tests se multiplicó por **10** con una plantilla casi constante; de ahí **25× jobs de CI en seis meses**. **(A)** La arquitectura v0 descansa sobre dos componentes que deben permanecer sincronizados — un *listener* que registra los resultados de cada ejecución, un *selector* que decide qué tests se ejecutan en cada PR — pero como **un único proceso**, un historial por test que asume un único escritor. **(B)** El modo de fallo es el listener quedándose atrás respecto a la cola de PR: *« 20 minutos de retraso del listener pueden traducirse en decenas de miles de actualizaciones de tests no aplicadas »*, con tres consecuencias nombradas — investigaciones desperdiciadas, *flaky reds* que bloquean los merges, un test corregido o añadido que no se ejecuta. **(C)** Tres parches cuya vida útil se derrumba — **70 días, 29 días, menos de un día**: una máquina más grande, sharding por paquete, reinicios diarios. Luego la revisión completa: un **magasin de données en mémoire**, workers *listener* **stateless** que por lo tanto son escalables horizontalmente, un log agregado cada pocos segundos. **Tres semanas para un ingeniero; un trimestre, un año antes.** Extiende el 80% de [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] hacia la infraestructura.

## Titre Article

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

## Date

2026-09-14

## URL

https://claude.com/blog/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic

## Keywords

integración continua, CI, test impact analysis, selección de tests, listener, selector, retraso del listener, 25× jobs de CI en seis meses, 80% del código escrito por Claude, flaky reds, datos de selección obsoletos, proceso único, escritor único, sharding por paquete, escalabilidad horizontal, workers stateless, magasin de données en mémoire, log, saturación de memoria, revisión completa del servicio, planificar lo exponencial, over-engineering, v0 dimensionada 10-20×, instrumentación, ojos y oídos de Claude, Claude Tag, sesión de larga duración, PR más pequeñas, carga a rachas

## Authors

Sachin Malhotra (ingénieur, Anthropic), sur le blog claude.com.

## Ton

**Perfil**: relato de ingeniería en primera persona, presentado como un post-mortem deliberado. Audiencia: equipos de plataforma, CI y herramientas para desarrolladores que verán venir la misma curva. Inglés directo, respaldado por un diagrama de arquitectura y un gráfico antes/después.

**Estilo**: el texto se construye sobre **una secuencia decreciente de cifras** — 70 días, 29 días, menos de un día — y esta secuencia *es* el argumento, mucho más que las técnicas empleadas. El propio autor las rebaja de antemano: comprar una máquina más grande, paralelizar, reiniciar el servicio *« (sí, este todavía funciona sorprendentemente bien) »* son *« comunes y no las lecciones que hay que sacar de este artículo »*. La lección se desplaza de los medios al **ritmo**: cada técnica compra una fracción del tiempo que compraba un año antes, mientras que la revisión completa también cuesta una fracción de lo que costaba antes. Dos capturas de pantalla de conversaciones ilustran el relato, honestamente etiquetadas — una *« recreada, basada en hechos reales »*, la otra textual con partes redactadas.

**Posición epistémica**: enteramente *de primera parte* y no auditable — la empresa mide sus propias herramientas con sus propios contadores, y las cifras más citadas (25×, 8×, 80%) son autodeclaradas. Dos admisiones dan valor al texto: la tendencia era legible pero *« la propiedad era confusa — nadie quería hacerse cargo de otra pieza más de infraestructura »*; y Claude, conectado a monitorización continua, **había estado defendiendo la revisión completa durante meses** mientras el equipo *« optaba por otro parche »*. El autor también acota el alcance del incidente en lugar de dramatizarlo: no se desplegó código sin testear a producción, la selección solo funcionaba con datos obsoletos.

## Pense-betes

- **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]].
- **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**.
- **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.
- **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.
- **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.
- **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 »*.
- **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.
- **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 »*.
- **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.
- **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.
- **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.

## RésuméDe400mots

Sachin Malhotra, ingeniero en Anthropic, relata cómo la empresa tuvo que revisar por completo su servicio de test impact analysis bajo la presión de la codificación agéntica. El punto de partida es una cadena de cifras: los ingenieros despliegan en promedio ocho veces más código por trimestre que entre 2021 y 2025, Claude escribe el 80% de él y desempeña un papel importante en la revisión y aprobación de PR, el número de tests se multiplicó por diez con una plantilla casi constante. El producto de todo esto es un aumento de veinticinco veces en los jobs de CI en seis meses. Escribir código ya no es la restricción; una vez que la revisión se acelera, es la CI la que absorbe la presión.

El servicio descansa sobre dos componentes deterministas que deben permanecer sincronizados: un listener, que registra los resultados de cada ejecución, y un selector, que lee este historial para decidir qué tests se ejecutan en cada PR. Mantener un historial por test requería un único escritor, de ahí un único proceso, de ahí la imposibilidad de hacer sharding horizontal. El modo de fallo es el listener quedándose atrás: veinte minutos bastan para dejar decenas de miles de actualizaciones sin aplicar, lo que desencadena investigaciones innecesarias, deja que tests flaky bloqueen los merges, e impide que un test corregido o añadido se ejecute.

Tres soluciones se sucedieron, cada una con una vida útil que se derrumba: duplicar los núcleos aguanta setenta días; el sharding por paquete — el listener no necesitaba un único escritor global sino uno por paquete, y Claude escribió el código para ello — aguanta veintinueve días; los reinicios diarios aguantan menos de un día. Mientras tanto, una sesión de larga duración en una versión interna de Claude Tag monitoriza el servicio y alerta más allá de cincuenta mil jobs de retraso acumulado; argumenta a favor de la revisión completa durante meses, pero el equipo prefiere el parche.

La revisión completa dota al servicio de un magasin de données en mémoire. Cada worker listener procesa cualquier resultado, lo añade a un log y sigue adelante sin retener 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 escalable y perfilable. Tres semanas para un ingeniero, frente a aproximadamente un trimestre un año antes.

Las lecciones se resumen en cuatro reglas: anticipar lo exponencial y asumir una carga veinticinco veces mayor dentro de dos trimestres, dimensionar la v0 entre diez y veinte veces la escala percibida, instrumentar los servicios para que sirvan de ojos y oídos de Claude, y mantener el estado fuera del proceso desde el principio.

## GrapheDeConnaissance

- Sachin Malhotra —travaille_chez→ Anthropic (ORGANISATION, 0.95)
- Anthropic —mesure→ 8× plus de code livré par ingénieur et par trimestre qu'en 2021-2025 (MESURE, 0.93)
- Anthropic —mesure→ Claude écrit 80 % du code livré et pèse largement dans la revue des PR (MESURE, 0.93)
- Anthropic —mesure→ ×10 sur le nombre de tests et ×25 sur les jobs CI en six mois (MESURE, 0.94)
- IA agentique —observé_dans→ déplacement du goulot de la génération de code vers l'intégration continue (AFFIRMATION, 0.92)
- Test impact analysis —s_applique_à→ Intégration continue (METHODOLOGIE, 0.94)
- Test impact analysis —utilise→ historique de résultats par test et pertinence par package (CONCEPT, 0.92)
- Test impact analysis —permet→ à un agent de s'auto-vérifier et d'itérer sur un jeu de tests pertinents (AFFIRMATION, 0.9)
- retard de listener —réduit→ fraîcheur des données de sélection des tests (CONCEPT, 0.9)
- retard de listener —mesure→ 20 minutes de retard = des dizaines de milliers de mises à jour non appliquées (MESURE, 0.92)
- retard de listener —observé_dans→ investigations inutiles, flaky reds bloquant les merges, test corrigé qui ne tourne pas (AFFIRMATION, 0.91)
- Claude Tag —observé_dans→ session longue de supervision du service, alerte au-delà de 50 000 jobs de retard (AFFIRMATION, 0.9)
- Claude Tag —recommande→ refondre le service plutôt qu'enchaîner les rustines (AFFIRMATION, 0.88)
- Magasin de données en mémoire —permet→ des workers listener sans état, donc scalables horizontalement (AFFIRMATION, 0.93)
- scalabilité horizontale —résout→ saturation mémoire du processus unique (CONCEPT, 0.91)
- Anthropic —mesure→ refonte livrée en trois semaines par un ingénieur, contre environ un trimestre un an plus tôt (MESURE, 0.92)
- Sachin Malhotra —affirme_que→ "Always plan for the exponential" (CITATION, 0.95)
- Sachin Malhotra —recommande→ supposer une charge ×25 dans les deux trimestres, qu'on construise ou qu'on achète (AFFIRMATION, 0.94)
- Sachin Malhotra —recommande→ dimensionner la v0 pour 10-20× l'échelle perçue si le budget le permet (AFFIRMATION, 0.92)
- Sachin Malhotra —recommande→ instrumenter les services pour qu'ils servent d'yeux et d'oreilles à Claude (AFFIRMATION, 0.92)
- Sachin Malhotra —recommande→ sortir l'état du processus dès le départ, jamais de service critique en instance unique (AFFIRMATION, 0.94)
- Sachin Malhotra —prédit→ l'architecture de sélection de tests scalée horizontalement deviendra un standard de l'industrie (AFFIRMATION, 0.88)
- IA agentique —observé_dans→ PR plus petites et granulaires, activité nocturne et de week-end, charge restant en rafales (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/es/fiches/malhotra-anthropic-ci-test-impact-analysis-2026-09-14/