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

## Veille

Post di ingegneria di **Anthropic** pubblicato il **14 settembre 2026** su claude.com/blog (~1.400 parole, cinque sezioni), scritto da **Sachin Malhotra**. Racconta la scalata del servizio di **test impact analysis** — la selezione dei test da eseguire per ogni modifica — sotto la pressione della programmazione agentica. I numeri di partenza e la loro concatenazione: gli ingegneri rilasciano in media **8×** più codice a trimestre rispetto al periodo 2021-2025, **Claude ne scrive l'80%** e pesa inoltre in modo significativo nella revisione e nell'approvazione delle PR; il numero di test è stato moltiplicato per **10** con un organico quasi costante; da cui **25× i job CI in sei mesi**. **(A)** L'architettura v0 si basa su due componenti che devono restare sincronizzati — un *listener* che registra i risultati di ogni esecuzione, un *selector* che decide quali test eseguire per ogni PR — ma come **processo unico**, una cronologia per singolo test che presuppone un solo writer. **(B)** La modalità di guasto è il listener che resta indietro rispetto alla coda delle PR: *« 20 minuti di ritardo del listener possono tradursi in decine di migliaia di aggiornamenti di test non applicati »*, con tre conseguenze indicate — investigazioni sprecate, *flaky reds* che bloccano i merge, un test corretto o aggiunto che non viene eseguito. **(C)** Tre correzioni la cui durata di vita collassa — **70 giorni, 29 giorni, meno di un giorno**: una macchina più grande, lo sharding per package, i riavvii giornalieri. Poi la revisione completa: un magasin de données en mémoire **in-memory**, worker *listener* **stateless** quindi scalabili orizzontalmente, un log aggregato ogni pochi secondi. **Tre settimane per un ingegnere; un trimestre, un anno prima.** Estende l'80% di [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] all'infrastruttura.

## 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

integrazione continua, CI, test impact analysis, selezione dei test, listener, selector, ritardo del listener, 25× i job CI in sei mesi, 80% del codice scritto da Claude, flaky reds, dati di selezione obsoleti, processo unico, writer unico, sharding per package, scalabilità orizzontale, worker stateless, magasin de données en mémoire, log, saturazione della memoria, revisione completa del servizio, pianificare per l'esponenziale, over-engineering, v0 dimensionata 10-20×, strumentazione, gli occhi e le orecchie di Claude, Claude Tag, sessione long-running, PR più piccole, carico bursty

## Authors

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

## Ton

**Profilo**: racconto ingegneristico in prima persona, presentato come un deliberato post-mortem. Pubblico: team di piattaforma, CI e developer-tooling che vedranno arrivare la stessa curva. Inglese diretto, corroborato da un diagramma architetturale e da un grafico prima/dopo.

**Stile**: il testo è costruito su **una sequenza decrescente di numeri** — 70 giorni, 29 giorni, meno di un giorno — e questa sequenza *è* l'argomento, molto più delle tecniche impiegate. L'autore stesso le sminuisce in anticipo: comprare una macchina più grande, parallelizzare, riavviare il servizio *« (sì, questa funziona ancora sorprendentemente bene) »* sono *« cose comuni e non gli insight da trarre da questo articolo »*. La lezione si sposta dai mezzi al **ritmo**: ogni tecnica compra una frazione del tempo che comprava un anno fa, mentre la revisione completa costa anch'essa una frazione di quanto costava in passato. Due screenshot di conversazioni illustrano il racconto, onestamente etichettati — uno *« ricreato, basato su eventi reali »*, l'altro testuale con redazioni.

**Posizione epistemica**: interamente *first-party* e non verificabile — l'azienda misura i propri strumenti con i propri contatori, e le cifre più citate (25×, 8×, 80%) sono autodichiarate. Due ammissioni danno valore al testo: la tendenza era leggibile ma *« la responsabilità era confusa — nessuno voleva farsi carico di un altro pezzo di infrastruttura »*; e Claude, collegato al monitoraggio continuo, **sosteneva da mesi la necessità della revisione completa** mentre il team *« si accontentava di un'altra correzione temporanea »*. L'autore delimita inoltre la portata dell'incidente invece di drammatizzarlo: nessun codice non testato è arrivato in produzione, la selezione funzionava solo su dati obsoleti.

## Pense-betes

- **La catena causale, non solo il numero.** 8× più codice rilasciato per ingegnere a trimestre, **l'80% scritto da Claude**, più un ruolo significativo dell'IA nella revisione e nell'approvazione delle PR; **×10 sul numero di test** con un organico quasi costante. Risultato: **×25 sui job CI in sei mesi**. *« Scrivere codice non è più il vincolo, e una volta accelerata la revisione delle PR, è la CI a sentire la pressione. »* Il collo di bottiglia non scompare, si sposta di un livello più in basso — una variante infrastrutturale del "collo di bottiglia della verifica" di [[sfeir-code-review-anneau-contraintes-2026-07-30]].
- **L'argomento specifico agli agenti**, il punto più trasferibile del testo. Eseguire tutto a ogni modifica funziona fino a un certo punto, poi i gate diventano lunghi, costosi e **non affidabili** — e quindi ignorati. Soprattutto: un umano sa scartare un fallimento di test che non lo riguarda, un agente no — ha bisogno di più contesto e direzione. Dato un insieme di test **valido e pertinente**, si autoverifica e itera da solo. La selezione dei test cessa di essere un'ottimizzazione dei costi e diventa una **condizione per l'autonomia**.
- **L'architettura v0 e il suo peccato originale**: mantenere una cronologia **per singolo test** richiedeva un solo writer, quindi un processo unico, quindi **nessuno sharding orizzontale possibile**. Lo stato viveva all'interno del processo.
- **La fisica del ritardo**: 20 minuti di ritardo = decine di migliaia di aggiornamenti non applicati. Tre conseguenze distinte — un merge difettoso fa fallire un test per tutti e innesca investigazioni superflue; una dipendenza che inizia a diventare flaky produce dei *reds* che bloccano i merge; un test corretto o aggiunto non viene eseguito finché il listener non si è aggiornato, con il rischio di una regressione.
- **Le tre correzioni e la loro emivita**: (1) raddoppiare i core — **70 giorni**; (2) **sharding per package** — il listener non necessitava di un solo writer globale, ma di un solo writer *per package*, e Claude ha generato il codice — **29 giorni**; (3) riavvii giornalieri — **meno di un giorno**, con solo quattro bug trovati, una modifica dell'allocatore di memoria senza alcun effetto, e il rifiuto deliberato di profilare la memoria di un singleton già sotto carico.
- **Supervisione delegata**, un dettaglio da trattenere: una **sessione long-running in una versione interna di Claude Tag** dedicata al servizio, che avvisa l'autore non appena il listener accumula più di **50.000 job di ritardo** e riprende la conversazione esattamente da dove l'aveva lasciata. Per mesi, senza dover ricaricare il contesto dei tentativi passati. E *« Claude ha spesso sostenuto la necessità di una revisione completa, ma di solito ci si accontentava di un'altra correzione temporanea »*.
- **La revisione completa**: dotare il servizio di una base — un magasin de données **en mémoire**. Qualsiasi worker *listener* elabora qualsiasi risultato, lo accoda a un **log** e prosegue senza trattenere nulla: stateless, quindi scalabile orizzontalmente. Un consumer separato aggrega il log in una cronologia per singolo test ogni pochi secondi. Più costoso da eseguire, ma **molto più facile da scalare e profilare** rispetto a un singleton fragile. La messa a punto (dimensione del log, numero di worker) è stata svolta in gran parte da Claude in autonomia.
- **L'economia della decisione è cambiata.** Tre settimane per un ingegnere, contro circa un trimestre un anno prima. Questo è il vero cambiamento: le mezze misure comprano sempre meno tempo mentre una revisione completa costa sempre meno — *« molto più sostenibile ora che scrivere codice non è più il collo di bottiglia »*.
- **Le quattro regole che ne trae**: presupporre che l'architettura affronterà **×25 il carico entro due trimestri**, sia che venga costruita sia che venga acquistata; accettare che l'over-engineering recede come errore — puntare a **10-20×** la scala percepita già dalla v0 se il budget lo consente; **strumentare i servizi perché fungano da occhi e orecchie di Claude**, come minimo l'invariante "tanti job CI in entrata quanti in uscita"; tenere lo stato fuori dal processo fin dall'inizio, non eseguire mai un servizio critico come istanza singola non misurabile.
- **La forma del carico cambia, non solo il suo volume**: Claude favorisce PR **più piccole e granulari** (un argomento in più contro l'esecuzione di ogni test su ogni PR), il livello minimo di attività si alza perché gli agenti effettuano push di notte e nei weekend, ma il carico **resta bursty** poiché gli umani guidano e approvano ancora una quota significativa delle PR.
- **La scommessa finale**, da verificare entro dodici mesi: *« prevedo che un'architettura di selezione dei test scalata orizzontalmente diventerà lo standard del settore »* poiché gli agenti producono sia più PR che più test.

## RésuméDe400mots

Sachin Malhotra, ingegnere presso Anthropic, racconta come l'azienda abbia dovuto rivedere completamente il proprio servizio di test impact analysis sotto la pressione della programmazione agentica. Il punto di partenza è una concatenazione di cifre: gli ingegneri rilasciano in media otto volte più codice a trimestre rispetto al periodo 2021-2025, Claude ne scrive l'80% e gioca un ruolo importante nella revisione e nell'approvazione delle PR, il numero di test è stato moltiplicato per dieci con un organico quasi costante. Il prodotto di tutto ciò è un aumento di venticinque volte dei job CI in sei mesi. Scrivere codice non è più il vincolo; una volta accelerata la revisione, è la CI ad assorbire la pressione.

Il servizio si basa su due componenti deterministiche che devono restare sincronizzate: un listener, che registra i risultati di ogni esecuzione, e un selector, che legge questa cronologia per decidere quali test eseguire per ogni PR. Mantenere una cronologia per singolo test richiedeva un solo writer, quindi un processo unico, quindi l'impossibilità di fare sharding orizzontale. La modalità di guasto è il listener che resta indietro: venti minuti bastano a lasciare decine di migliaia di aggiornamenti non applicati, il che innesca investigazioni superflue, permette ai test flaky di bloccare i merge e impedisce l'esecuzione di un test corretto o aggiunto.

Si susseguono tre correzioni, ciascuna con una durata di vita in calo: raddoppiare i core tiene per settanta giorni; lo sharding per package — il listener non necessitava di un solo writer globale ma di uno per package, e Claude ne ha scritto il codice — tiene per ventinove giorni; i riavvii giornalieri tengono per meno di un giorno. Nel frattempo, una sessione long-running in una versione interna di Claude Tag monitora il servizio e avvisa oltre i cinquantamila job di arretrato; sostiene per mesi la necessità di una revisione completa, ma il team preferisce la correzione temporanea.

La revisione completa dota il servizio di un magasin de données en mémoire. Ogni worker listener elabora qualsiasi risultato, lo accoda a un log e prosegue senza trattenere nulla: stateless, quindi scalabile orizzontalmente. Un consumer separato aggrega il log in una cronologia per singolo test ogni pochi secondi. Più costoso da eseguire, ma scalabile e profilabile. Tre settimane per un ingegnere, contro circa un trimestre un anno prima.

Le lezioni si riducono a quattro regole: anticipare l'esponenziale e presupporre un carico venticinque volte superiore entro due trimestri, dimensionare la v0 a dieci-venti volte la scala percepita, strumentare i servizi perché fungano da occhi e orecchie di Claude, e tenere lo stato fuori dal processo fin dall'inizio.

## 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/it/fiches/malhotra-anthropic-ci-test-impact-analysis-2026-09-14/