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

Punti chiave

1. 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]].
2. 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.
3. 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.
4. 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.
5. 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.
6. 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 ».
7. 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.
8. 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 ».
9. 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.
10. 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.
11. 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.