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

## Veille

Engineering-Beitrag von **Anthropic**, veröffentlicht am **14. September 2026** auf claude.com/blog (~1.400 Wörter, fünf Abschnitte), verfasst von **Sachin Malhotra**. Er schildert die Skalierung des **Test-Impact-Analyse**-Dienstes — der Auswahl, welche Tests bei welcher Änderung laufen — unter dem Druck des agentischen Codings. Die Ausgangszahlen und ihre Kausalkette: Die Entwickler liefern im Schnitt **8×** mehr Code pro Quartal als 2021–2025, **Claude schreibt 80 % davon** und trägt auch bei PR-Review und -Freigabe erheblich bei; die Anzahl der Tests wurde bei annähernd konstanter Teamgröße mit **10** multipliziert; daraus folgen **25× CI-Jobs in sechs Monaten**. **(A)** Die v0-Architektur beruht auf zwei Komponenten, die synchron bleiben müssen — einem *Listener*, der die Ergebnisse jedes Laufs erfasst, und einem *Selector*, der entscheidet, welche Tests bei jedem PR laufen —, jedoch als **einziger Prozess**, mit einer Pro-Test-Historie, die einen einzigen Writer voraussetzt. **(B)** Der Fehlermodus besteht darin, dass der Listener hinter die PR-Warteschlange zurückfällt: *« 20 Minuten Listener-Verzögerung können bedeuten, dass Zehntausende Testaktualisierungen nicht übernommen werden »*, mit drei benannten Folgen — verschwendete Untersuchungen, *flaky reds*, die Merges blockieren, ein behobener oder hinzugefügter Test, der nicht läuft. **(C)** Drei Patches, deren Lebensdauer einbricht — **70 Tage, 29 Tage, weniger als ein Tag**: eine größere Maschine, Sharding nach Package, tägliche Neustarts. Dann die Grundüberarbeitung: ein **arbeitsspeicherbasiertes** magasin de données en mémoire, **zustandslose** *Listener*-Worker, die dadurch horizontal skalierbar sind, ein alle paar Sekunden aggregiertes Log. **Drei Wochen für einen Entwickler; ein Jahr zuvor ein Quartal.** Erweitert die 80 % aus [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] auf die Infrastruktur.

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

Continuous Integration, CI, Test-Impact-Analyse, Testauswahl, Listener, Selector, Listener-Verzögerung, 25× CI-Jobs in sechs Monaten, 80 % des Codes von Claude geschrieben, flaky reds, veraltete Auswahldaten, einziger Prozess, einziger Writer, Sharding nach Package, horizontale Skalierbarkeit, zustandslose Worker, magasin de données en mémoire, Log, Speichersättigung, Grundüberarbeitung des Dienstes, Planung für das Exponentielle, Over-Engineering, v0 im 10- bis 20-Fachen dimensioniert, Instrumentierung, Claudes Augen und Ohren, Claude Tag, Dauer-Session, kleinere PRs, stoßweise Last

## Authors

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

## Ton

**Profil**: Ingenieurbericht in der Ich-Form, als bewusster Post-Mortem angelegt. Zielgruppe: Platform-, CI- und Developer-Tooling-Teams, die dieselbe Kurve kommen sehen werden. Direktes Englisch, gestützt durch ein Architekturdiagramm und ein Vorher/Nachher-Chart.

**Stil**: Der Text baut auf **einer abnehmenden Zahlenfolge** auf — 70 Tage, 29 Tage, weniger als ein Tag — und diese Folge *ist* das Argument, weit mehr als die eingesetzten Techniken. Der Autor selbst stuft sie vorab herab: eine größere Maschine kaufen, parallelisieren, den Dienst neu starten *« (ja, das funktioniert immer noch überraschend gut) »* seien *« üblich und nicht die Erkenntnisse, die man aus diesem Artikel mitnehmen sollte »*. Die Lehre verschiebt sich von den Mitteln zum **Tempo**: Jede Technik kauft nur noch einen Bruchteil der Zeit, die sie ein Jahr zuvor kaufte, während die Grundüberarbeitung ebenfalls nur noch einen Bruchteil dessen kostet, was sie früher kostete. Zwei Konversations-Screenshots illustrieren den Bericht, ehrlich beschriftet — einer als *« nachgestellt, basierend auf echten Ereignissen »*, der andere wortgetreu mit Schwärzungen.

**Epistemische Position**: durchweg *erster Hand* und nicht überprüfbar — das Unternehmen misst sein eigenes Tooling mit eigenen Zählern, und die am häufigsten zitierten Zahlen (25×, 8×, 80 %) sind Eigenangaben. Zwei Eingeständnisse geben dem Text seinen Wert: Der Trend war erkennbar, aber *« die Zuständigkeit war unklar — niemand wollte ein weiteres Stück Infrastruktur übernehmen »*; und Claude, an eine kontinuierliche Überwachung angebunden, **hatte monatelang für die Grundüberarbeitung plädiert**, während das Team sich *« für einen weiteren Patch entschied »*. Der Autor grenzt zudem den Umfang des Vorfalls ein, statt ihn zu dramatisieren: Kein ungetesteter Code ging in Produktion, die Auswahl arbeitete lediglich mit veralteten Daten.

## Pense-betes

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

## RésuméDe400mots

Sachin Malhotra, Ingenieur bei Anthropic, schildert, wie das Unternehmen seinen Test-Impact-Analyse-Dienst unter dem Druck des agentischen Codings grundlegend überarbeiten musste. Ausgangspunkt ist eine Zahlenkette: Die Entwickler liefern im Schnitt achtmal mehr Code pro Quartal als zwischen 2021 und 2025, Claude schreibt 80 % davon und spielt bei PR-Review und -Freigabe eine wesentliche Rolle, die Anzahl der Tests wurde bei annähernd konstanter Teamgröße mit zehn multipliziert. Das Ergebnis all dessen ist eine Verfünfundzwanzigfachung der CI-Jobs in sechs Monaten. Das Schreiben von Code ist nicht mehr der limitierende Faktor; sobald das Review beschleunigt wird, ist es die CI, die den Druck auffängt.

Der Dienst beruht auf zwei deterministischen Komponenten, die synchron bleiben müssen: einem Listener, der die Ergebnisse jedes Laufs erfasst, und einem Selector, der diese Historie liest, um zu entscheiden, welche Tests bei jedem PR laufen. Das Führen einer Pro-Test-Historie erforderte einen einzigen Writer, somit einen einzigen Prozess, somit die Unmöglichkeit, horizontal zu shard-en. Der Fehlermodus besteht darin, dass der Listener zurückfällt: Zwanzig Minuten reichen aus, um Zehntausende Aktualisierungen nicht übernommen zu lassen, was unnötige Untersuchungen auslöst, flaky Tests Merges blockieren lässt und verhindert, dass ein behobener oder hinzugefügter Test läuft.

Drei Korrekturen folgen aufeinander, jede mit einbrechender Lebensdauer: die Verdopplung der Kerne hält siebzig Tage; Sharding nach Package — der Listener brauchte keinen einzigen globalen Writer, sondern einen pro Package, und Claude schrieb den Code dafür — hält neunundzwanzig Tage; tägliche Neustarts halten weniger als einen Tag. In der Zwischenzeit überwacht eine Dauer-Session in einer internen Version von Claude Tag den Dienst und alarmiert ab einem Rückstand von fünfzigtausend Jobs; sie plädiert monatelang für die Grundüberarbeitung, doch das Team bevorzugt den Patch.

Die Grundüberarbeitung gibt dem Dienst ein magasin de données en mémoire. Jeder 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 skalierbar und profilierbar. Drei Wochen für einen Entwickler, gegenüber etwa einem Quartal ein Jahr zuvor.

Die Lehren lassen sich auf vier Regeln verdichten: das Exponentielle antizipieren und innerhalb von zwei Quartalen eine fünfundzwanzigfach höhere Last annehmen, das v0 auf das Zehn- bis Zwanzigfache der wahrgenommenen Größenordnung dimensionieren, Dienste so instrumentieren, dass sie als Claudes Augen und Ohren dienen, und den Zustand von Anfang an aus dem Prozess heraushalten.

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