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

À retenir

1. La chaîne causale, pas seulement le chiffre. 8× de code livré par ingénieur et par trimestre, dont 80 % écrit par Claude, plus un rôle important de l'IA dans la revue et l'approbation des PR ; ×10 sur le nombre de tests à effectifs quasi constants. Résultat : ×25 sur les jobs CI en six mois. « Writing code is no longer the constraint, and once PR review gets accelerated, CI starts feeling the pressure. » Le goulot ne disparaît pas, il descend d'un cran — variante infrastructurelle du « col étroit de la vérification » de [[sfeir-code-review-anneau-contraintes-2026-07-30]].
2. L'argument propre aux agents. , le plus transposable du texte. Tout exécuter sur chaque changement marche jusqu'à un point, puis les gates deviennent longs, coûteux et non fiables — donc ignorés. Surtout : un humain sait écarter un échec de test qui ne le concerne pas, un agent non — il lui faut plus de contexte et de direction. Donné un jeu de tests valides et pertinents, il s'auto-vérifie et itère seul. La sélection de tests cesse d'être une optimisation de coût pour devenir une condition de l'autonomie.
3. L'architecture v0 et son péché originel. tenir un historique par test imposait un écrivain unique, donc un processus unique, donc aucun sharding horizontal possible. L'état était dans le processus.
4. La physique du retard. 20 minutes de lag = des dizaines de milliers de mises à jour non appliquées. Trois conséquences distinctes — un mauvais merge fait échouer un test pour tout le monde et déclenche des investigations inutiles ; une dépendance qui se met à flaker produit des reds qui bloquent les merges ; un test corrigé ou ajouté ne tourne pas tant que le listener n'a pas rattrapé, au risque d'une régression.
5. Les trois rustines et leur demi-vie. (1) doubler les cœurs — 70 jours ; (2) sharder par package — le listener n'avait pas besoin d'un écrivain unique global, mais d'un écrivain unique par package, et Claude a généré le code — 29 jours ; (3) redémarrages quotidiens — moins d'un jour, avec seulement quatre bugs trouvés, un changement d'allocateur mémoire sans effet, et le refus assumé de profiler la mémoire d'un singleton déjà sous charge.
6. La supervision déléguée. , détail à retenir : une session longue dans une version interne de Claude Tag dédiée au service, qui alerte l'auteur dès que le listener dépasse 50 000 jobs de retard et reprend la conversation là où elle s'était arrêtée. Pendant des mois, sans avoir à recharger le contexte des tentatives passées. Et « Claude often argued for an overhaul, but we usually settled on another patch ».
7. La refonte. donner une base au service — un magasin de données en mémoire. N'importe quel worker listener traite n'importe quel résultat, l'ajoute à un journal et repart sans rien garder : sans état, donc scalable horizontalement. Un consommateur séparé agrège le journal en historique par test toutes les quelques secondes. Plus cher à exploiter, mais beaucoup plus facile à scaler et à profiler qu'un singleton fragile. Le réglage fin (taille du journal, nombre de workers) a été fait par Claude en grande partie seul.
8. L'économie de la décision a changé. Trois semaines pour un ingénieur, contre environ un trimestre un an plus tôt. C'est le vrai basculement : les demi-mesures achètent de moins en moins de temps pendant que la refonte en coûte de moins en moins — « much more sustainable now that writing code is no longer the bottleneck ».
9. Les quatre règles qu'il en tire. supposer l'architecture à ×25 de charge dans deux trimestres, qu'on construise ou qu'on achète ; admettre que la sur-ingénierie recule comme faute — viser 10-20× l'échelle perçue dès la v0 si le budget suit ; instrumenter les services pour qu'ils servent d'yeux et d'oreilles à Claude, au minimum l'invariant « autant de jobs CI entrants que sortants » ; sortir l'état du processus dès le départ, jamais de service critique en instance unique non mesurable.
10. La forme de la charge change, pas seulement son volume. Claude préfère des PR plus petites et plus granulaires (argument de plus contre l'exécution de tous les tests sur chaque PR), le plancher d'activité monte parce que les agents poussent la nuit et le week-end, mais la charge reste en rafales puisque les humains pilotent et approuvent encore une part significative des PR.
11. Le pari final. , à vérifier dans douze mois : « I anticipate horizontally scaled test selection architecture will become industry standard » à mesure que les agents produisent à la fois plus de PR et plus de tests.