Um den Faktor 25 sind die CI-Jobs im Anthropic-Engineering in einem halben Jahr gewachsen. Die Zahl der Tests stieg auf das Zehnfache, neue Engineers wurden praktisch keine eingestellt. Ein Engineer des Unternehmens beschreibt in einem Erfahrungsbericht im firmeneigenen Blog auf claude.com, wie sein Test-Impact-Analysis-Service dadurch mehrfach an die Belastungsgrenze geriet und am Ende komplett neu gebaut werden musste. Wer heute mit KI-Agenten Software entwickelt, sollte das als Frühwarnung lesen: Was bei Anthropic in verschärfter Form passiert ist, kommt in abgeschwächter Variante auf viele Teams zu.
Interessanter als die Technik sind die Zeitmaßstäbe. Drei klassische Rettungsmaßnahmen – größere Maschine, mehr Parallelität, regelmäßiger Neustart – hielten diesmal nur noch 70 Tage, dann 29, dann weniger als einen Tag. Ein Jahr zuvor hätte jede davon deutlich länger getragen. Gleichzeitig dauerte der vollständige Umbau des Dienstes nur drei Wochen statt eines Quartals. Genau das macht Agentic Coding mit Continuous Integration: Der Engpass verschiebt sich, die Werkzeuge dagegen werden schneller und kurzlebiger.
Warum 80 Prozent des Codes aus dem Agenten kommen und die CI trotzdem leidet
Laut dem Bericht liefern Engineers bei Anthropic pro Quartal achtmal so viel Code ab wie zwischen 2021 und 2025. Rund 80 Prozent davon stammt von Claude, und das Modell ist auch am Reviewen und Abnehmen von Pull Requests beteiligt. Code zu schreiben ist damit nicht mehr der Engpass. Sobald aber auch das Review schneller wird, landet mehr fertiger Code in kürzerer Zeit bei der CI, und die ist auf dieses Tempo nicht ausgelegt.
Parallel wuchs die Testsuite im Repository auf das Zehnfache, ohne dass die Zahl der Engineers mitstieg. Über sechs Monate ergab das einen Anstieg der CI-Jobs um den Faktor 25. Die Rechnung geht nur deshalb nicht völlig auf, weil nicht jeder Test bei jedem Pull Request läuft; dazu später mehr. Das Muster dahinter zählt: Agenten erzeugen mehr Code, mehr Tests, mehr kleinere Pull Requests und mehr Aktivität außerhalb klassischer Arbeitszeiten. Der Grundpegel steigt, die Spitzen bleiben.
Wie der Test Impact Analysis Service arbeitet und warum ein einzelner Schreiber zum Problem wird
Anthropic betreibt einen deterministischen Test-Impact-Analysis-Service, der anhand vergangener Testergebnisse und Paketabhängigkeiten entscheidet, welche Tests bei welcher Änderung laufen. Die Idee ist nicht neu, es gibt eine ganze Kategorie von Anbietern für diese Testauswahl. Der Dienst besteht aus zwei Komponenten, die synchron bleiben müssen: Ein Listener zeichnet die Testergebnisse jedes CI-Laufs auf, ein Selector liest diese Historie und legt fest, welche Tests für einen geöffneten Pull Request relevant sind.
Das ist wie ein Wasserwerk. Der Listener ist der Abfluss, der alles aufnimmt, was oben ankommt; der Selector ist die Steuerung, die daraus ableitet, wohin das Wasser fließen soll. Bei moderatem Zufluss funktioniert das unspektakulär. Treffen aber jede Sekunde mehrere CI-Jobs ein, kommt der Abfluss nicht mehr hinterher. Und weil die Testhistorie pro Test einen einzigen schreibenden Prozess braucht, ließ sich das System nicht ohne Weiteres auf mehrere Maschinen verteilen. Diese v0-Architektur verhinderte jedes horizontale Sharding.
Die Folgen sind subtiler, als sie klingen. Zwanzig Minuten Verzögerung im Listener bedeuten dem Autor zufolge leicht Zehntausende Testergebnis-Updates, die der Selector nie sieht. Wird eine fehlerhafte Änderung gemergt, schlägt ein Test anschließend für alle anderen fehl und erzeugt unnötige Untersuchungen. Fängt eine Abhängigkeit an zu flackern, blockieren instabile rote Läufe die Merges. Wird ein Test repariert oder ein neuer hinzugefügt, läuft er erst, wenn der Listener aufgeholt hat – mit entsprechendem Regressionsrisiko. In einem KI-gestützten Entwicklungszyklus ist schon eine kleine Verzögerung teuer, weil Agenten für selbstständige Iteration auf verlässliche Rückmeldung angewiesen sind.
Drei Flicken und ihre Halbwertszeiten: 70 Tage, 29 Tage, weniger als ein Tag
Im Oktober 2025 zeigte der Dienst erste Ermüdungserscheinungen, das Team wurde zwei Tage hintereinander alarmiert. Der erste Patch war naheliegend: doppelt so viele Kerne. Das hielt 70 Tage. Erschwerend kam hinzu, dass die Zuständigkeit unklar war. Niemand wollte ein weiteres Stück Infrastruktur verantworten, und das CI-Team hatte selbst genug zu tun. Der Autor startete daraufhin eine dauerhafte Sitzung in einer internen Version von Claude Tag, die den Dienst überwachte und sich meldete, sobald der Listener mehr als 50.000 Jobs im Rückstand war. Über Monate sammelte sich so Kontext, ohne dass ihn jedes Mal jemand neu erklären musste.
Im Februar 2026 kam der zweite Patch: Parallelisierung. Der Listener brauchte keinen einzigen Schreiber für die gesamte Historie, sondern einen pro Paket, damit die Reihenfolge innerhalb jedes Codeabschnitts stimmt. Claude generierte den Code, der den Zustand jedes Pakets in einen eigenen Shard mit eigenem Worker aufteilte. Diese Maßnahme hielt 29 Tage. Im März 2026 erreichte der Prozess an den meisten Werktagen schon am Nachmittag sein Speicherlimit. Die Suche nach schnellen Auswegen blieb erfolglos: vier gefundene Bugs, ein wirkungsloser Wechsel des Speicherallokators, erfolglose Versuche an der Garbage Collection, und ein Memory-Profiling an dem ohnehin schwer belasteten Singleton wollte niemand riskieren. Tägliche Neustarts brachten weniger als einen Tag und sorgten dafür, dass der Dienst langsam immer weiter zurückfiel.
Wichtig ist die Einordnung, die der Autor selbst vornimmt: Fielen Ergebnisse aus, bedeutete das nicht, dass CI gar nicht lief oder ungetesteter Code in Produktion ging. Es bedeutete, dass die Testauswahl mit veralteten Daten entschied und dadurch bevorzugt Tests einplante, die ohnehin flackernd oder breitflächig rot waren. Das ist kein Sicherheitsproblem, sondern ein Effizienz- und Vertrauensproblem. Genau daran merkt man, dass die Testselektion für Pull Requests kein Nebenschauplatz mehr ist, sondern kritische Infrastruktur.
Der Umbau: Zustand raus aus dem Prozess, Journal rein
Am Ende folgte das Team dem Rat des Agenten und gab dem Dienst eine Datenbank, genauer einen In-Memory-Datastore. Damit verlagerte sich ein großer Teil der Verarbeitung aus dem Speicher des Singleton-Prozesses heraus. Jeder Listener-Worker kann nun ein beliebiges Ergebnis verarbeiten, es an ein Journal im Store anhängen und weitermachen, ohne etwas im Speicher zu halten. Der Dienst ist damit zustandslos und horizontal skalierbar.
Ein kleiner, separater Consumer-Prozess rollt das Journal alle paar Sekunden zu einer Historie pro Test zusammen, aus der der Selector die relevante Vorgeschichte schnell nachschlagen kann. Das ist teurer im Betrieb als ein einzelner Prozess, aber deutlich einfacher zu skalieren und zu profilen. Der Umbau dauerte drei Wochen für einen einzigen Engineer; ein Jahr zuvor hätte dasselbe Projekt eher ein Quartal gebraucht. Die Feinarbeit – Größe des Journals, Anzahl der Worker – erledigte Claude weitgehend autonom. Seit dem Umschnitt bleibt der Rückstand flach, wo vorher täglich ein Berg entstand.
Was Teams jetzt einplanen sollten: 25-fache Last in zwei Quartalen
Die eigentliche Lehre des Berichts ist keine Technik, sondern eine Planungsannahme: Wer heute eine CI-Architektur entwirft, sollte davon ausgehen, dass sie innerhalb von zwei Quartalen das 25-Fache der heutigen Last tragen muss. Der Autor empfiehlt, in v0-Designs bereits das Zehn- bis Zwanzigfache der gefühlten Skalierung einzuplanen, solange das Budget es hergibt. Was als Überkonstruktion gilt, verschiebt sich damit nach oben.
Dazu kommen drei praktische Regeln. Erstens: Instrumentiere die Dienste so, dass ein Agent sie wie Augen und Ohren nutzen kann, um Probleme inkrementell zu erkennen und zu beheben. Insbesondere sollte die Zahl der eingehenden CI-Jobs der Zahl der ausgehenden entsprechen, sonst wächst irgendwo ein Rückstand. Zweitens: Halte Zustand von Anfang an aus dem Prozess heraus, weil zustandsbehaftete Dienste jede horizontale Skalierung blockieren. Drittens: Betreibe kritische Dienste nicht als einzelne Instanz, es sei denn, du kannst sie messen und Canary-Änderungen fahren. Klingt banal, entscheidet aber darüber, wie viel Zeit ein Vorfall kostet.
Testauswahl wird zur Infrastrukturfrage
Der Bericht zeigt eine Verschiebung, die über Anthropic hinausgeht. Solange Menschen Code schrieben und reviewten, war die Testauswahl eine Optimierung: nett, aber verzichtbar, weil ein paar zusätzliche Tests pro Pull Request niemanden umbrachten. Sobald Agenten Code und Reviews beschleunigen, kippt diese Logik. Jeder unnötig eingeplante Test kostet dann nicht mehr ein paar Minuten eines Menschen, sondern blockiert den Selbstverifikationszyklus eines Agenten, der auf präzise Rückmeldung angewiesen ist. Umgekehrt reicht es nicht, den bestehenden Dienst einfach größer zu machen: Seine Architektur muss von vornherein auf horizontale Skalierung der Testauswahl ausgelegt sein.
Für Teams, die KI-gestützte Softwareentwicklung und Continuous Integration zusammenbringen wollen, heißt das konkret: Prüfe, ob dein Listener und dein Selector überhaupt unabhängig skalieren können. Miss den Rückstand als Kennzahl, nicht nur die Laufzeit der Pipeline. Und kalkuliere den exponentiellen Verlauf ein, statt ihn als Ausnahmefall zu behandeln. Die gute Nachricht des Berichts: Der Umbau selbst ist billiger geworden, weil Code zu schreiben kein Engpass mehr ist. Die schlechte: Dieselbe Beschleunigung baut den Druck auf, der ihn nötig macht. Halbe Lösungen kosten am Ende mehr Zeit.
Quelle: claude.com
