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

Kernpunkte

1. Die Kausalkette, nicht nur die Zahl. 8× mehr ausgelieferter Code pro Entwickler und Quartal, 80 % davon von Claude geschrieben, dazu eine erhebliche Rolle der KI bei PR-Review und -Freigabe; ×10 bei der Anzahl der Tests bei annähernd konstanter Teamgröße. Ergebnis: ×25 bei den CI-Jobs in sechs Monaten. « Das Schreiben von Code ist nicht mehr der limitierende Faktor, und sobald das PR-Review beschleunigt wird, beginnt die CI, den Druck zu spüren. » Der Engpass verschwindet nicht, er verschiebt sich eine Ebene tiefer — eine infrastrukturelle Variante des „Verifikations-Engpasses" aus [[sfeir-code-review-anneau-contraintes-2026-07-30]].
2. Das agentenspezifische Argument. , der am meisten übertragbare Punkt des Textes. Alles bei jeder Änderung laufen zu lassen funktioniert bis zu einem gewissen Punkt, dann werden die Gates lang, teuer und unzuverlässig — und damit ignoriert. Vor allem: Ein Mensch weiß, einen Testfehler, der ihn nicht betrifft, zu verwerfen, ein Agent nicht — er braucht mehr Kontext und Steuerung. Bei einem validen und relevanten Testset verifiziert er sich selbst und iteriert eigenständig. Die Testauswahl ist dann keine Kostenoptimierung mehr, sondern wird zur Voraussetzung für Autonomie.
3. Die v0-Architektur und ihre Erbsünde. Das Führen einer Pro-Test-Historie erforderte einen einzigen Writer, somit einen einzigen Prozess, somit keine horizontale Shard-Möglichkeit. Der Zustand lebte innerhalb des Prozesses.
4. Die Physik der Verzögerung. 20 Minuten Verzögerung = Zehntausende nicht übernommene Aktualisierungen. Drei unterschiedliche Folgen — ein fehlerhafter Merge lässt einen Test für alle fehlschlagen und löst unnötige Untersuchungen aus; eine Abhängigkeit, die anfängt zu flackern, erzeugt reds, die Merges blockieren; ein behobener oder hinzugefügter Test läuft erst, wenn der Listener aufgeholt hat, was eine Regression riskiert.
5. Die drei Patches und ihre Halbwertszeit. (1) Verdopplung der Kerne — 70 Tage; (2) Sharding nach Package — der Listener brauchte keinen einzigen globalen Writer, sondern einen einzigen Writer pro Package, und Claude generierte den Code dafür — 29 Tage; (3) tägliche Neustarts — weniger als ein Tag, mit nur vier gefundenen Bugs, einer wirkungslosen Änderung des Memory-Allocators und der bewussten Ablehnung, den Speicher eines bereits unter Last stehenden Singletons zu profilieren.
6. Delegierte Überwachung. , ein Detail, das man sich merken sollte: eine Dauer-Session in einer internen Version von Claude Tag, die dem Dienst gewidmet ist und den Autor alarmiert, sobald der Listener mehr als 50.000 Jobs zurückfällt, und das Gespräch dort wieder aufnimmt, wo es aufgehört hat. Monatelang, ohne den Kontext früherer Versuche neu laden zu müssen. Und « Claude plädierte oft für eine Grundüberarbeitung, aber wir entschieden uns meist für einen weiteren Patch ».
7. Die Grundüberarbeitung. Dem Dienst ein Fundament geben — ein magasin de données en mémoire. Jeder beliebige Listener-Worker verarbeitet ein beliebiges Ergebnis, hängt es an ein Log an und macht weiter, ohne etwas zu behalten: zustandslos, somit horizontal skalierbar. Ein separater Consumer aggregiert das Log alle paar Sekunden zur Pro-Test-Historie. Teurer im Betrieb, aber deutlich leichter zu skalieren und zu profilieren als ein fragiles Singleton. Die Feinabstimmung (Log-Größe, Anzahl der Worker) übernahm größtenteils Claude selbständig.
8. Die Ökonomie der Entscheidung hat sich verändert. Drei Wochen für einen Entwickler, gegenüber etwa einem Quartal ein Jahr zuvor. Das ist die eigentliche Verschiebung: Halbmaßnahmen kaufen immer weniger Zeit, während eine Grundüberarbeitung immer weniger kostet — « weitaus nachhaltiger jetzt, wo das Schreiben von Code nicht mehr der Engpass ist ».
9. Die vier Regeln, die er daraus ableitet. davon ausgehen, dass die Architektur innerhalb von zwei Quartalen mit ×25 der Last konfrontiert wird, ob selbst gebaut oder zugekauft; akzeptieren, dass Over-Engineering als Fehler in den Hintergrund tritt — bereits bei v0 das 10- bis 20-Fache der wahrgenommenen Größenordnung anstreben, falls das Budget es erlaubt; Dienste so instrumentieren, dass sie als Claudes Augen und Ohren dienen, mindestens mit der Invariante „so viele CI-Jobs rein wie raus"; den Zustand von Anfang an aus dem Prozess heraushalten, einen kritischen Dienst nie als nicht messbare Einzelinstanz betreiben.
10. Die Form der Last ändert sich, nicht nur ihr Volumen. Claude bevorzugt kleinere, granularere PRs (ein weiteres Argument gegen das Ausführen jedes Tests bei jedem PR), die Aktivitätsgrundlinie steigt, weil Agenten nachts und am Wochenende pushen, aber die Last bleibt stoßweise, da Menschen weiterhin einen erheblichen Anteil der PRs steuern und freigeben.
11. Die abschließende Wette. , in zwölf Monaten zu überprüfen: « Ich erwarte, dass horizontal skalierte Testauswahl-Architekturen zum Industriestandard werden », da Agenten sowohl mehr PRs als auch mehr Tests produzieren.