Anthropic hat am 14. September einen Beitrag im Engineering-Blog veröffentlicht. Autor Sachin Malhotra beschreibt darin, wie ein interner Dienst des Unternehmens unter der Last zusammenbrach und neu geschrieben werden musste. Der Dienst heißt Test Impact Analysis, seine Aufgabe ist eigentlich simpel: Bei jeder eingehenden Codeänderung soll er entscheiden, welche Tests laufen müssen und welche übersprungen werden können. Das klingt nach einer Backend-Komponente im Hintergrund, doch der Grund für ihren Zusammenbruch ist durchaus typisch.
Erst ein paar Vervielfachungen
Die erste Zahlenreihe im Blogbeitrag betrifft die Ausstoßseite: Anthropic-Ingenieure liefern inzwischen pro Quartal im Schnitt das Achtfache dessen, was im Zeitraum 2021 bis 2025 üblich war, 80 Prozent davon geschrieben von Claude. Claude übernimmt zudem einen erheblichen Anteil beim Review und bei der Freigabe von Pull Requests.
Die zweite Zahlenreihe betrifft die Belastungsseite: Die Gesamtzahl der Tests im Repository hat sich verzehnfacht, die Anzahl der CI-Jobs ist innerhalb von sechs Monaten um das 25-Fache gestiegen.
Die dritte Zahlenreihe zeigt das Tempo am deutlichsten. Um der Last standzuhalten, hat das Team drei befristete Notlösungen ausgerollt, die jeweils 70 Tage, 29 Tage und weniger als einen Tag Zeit erkauften. Die dritte Lösung war noch am Tag ihrer Einführung aufgebraucht.
Wo der alte Dienst hakte
Die alte Architektur hatte einen Single-Process-Listener, der jedes Testergebnis der Reihe nach in den Speicher schreiben musste. Ein einzelner Schreibpfad bedeutet, dass sich das System nicht horizontal skalieren lässt — sobald die Rate eingehender Pull Requests die Verarbeitungsgeschwindigkeit überstieg, staute sich die Warteschlange. Im Blogbeitrag heißt es wörtlich, der Listener "starts to increasingly fall behind the PR queue".
Die Verzögerung zog Folgen nach sich, die sich gegenseitig verstärkten. Als Beispiel nennt der Beitrag eine Verzögerung von 20 Minuten, die bedeutete, dass zehntausende Testergebnis-Updates noch nicht im Speicher angekommen waren. Da die Testauswahl gerade auf historischen Ergebnissen beruht, macht eine ungenaue Historie die ausgewählte Testmenge unzuverlässig. Erschwerend kam hinzu, dass der Prozess ein Memory Leak hatte und jeden Nachmittag an seine Obergrenze stieß.
Was daraus wurde
Die Idee der Neufassung war, den Zustand aus dem Prozess herauszulösen. Die neue Architektur führt einen In-Memory-Datenspeicher ein: Jeder Listener-Worker kann jedes beliebige Ergebnis verarbeiten, er hängt es nur an ein Log an und hält selbst keinen Zustand — dadurch lassen sich bei Bedarf einfach weitere Maschinen hinzufügen. Ein separater Consumer-Prozess fasst das Log alle paar Sekunden zu einer nach einzelnen Tests organisierten Historie zusammen. Muss der Selector eine Entscheidung treffen, fragt er direkt diese Historie ab.
Der Preis dafür sind höhere Kosten. Der Blogbeitrag räumt das ein und begründet es mit dem Gegenwert aus Skalierbarkeit und Beobachtbarkeit — welcher Schritt langsam ist und woran es liegt, lässt sich jetzt einzeln messen. Das gesamte Redesign hat ein einzelner Ingenieur in drei Wochen umgesetzt.
Diese Kurve mit dem Faktor 25
25-fach in sechs Monaten entspricht umgerechnet einer monatlichen Wachstumsrate von etwa dem 1,71-Fachen (grob gerechnet: die sechste Wurzel aus 25). Zieht man diese Steigung weitere sechs Monate durch, ergibt sich das 625-Fache. Der Satz "always plan for the exponential" am Ende des Beitrags ist keine Floskel, sondern bezieht sich auf eine bereits gemessene Kurve.
Die Extrapolation dieser Kurve ist natürlich nicht zuverlässig — die Wachstumsrate kann sich durch interne Richtlinien, Kontingente oder veränderte Arbeitsgewohnheiten der Ingenieure verändern. Anthropic hat auch keine absoluten CI-Kosten veröffentlicht, keine Angabe gemacht, welcher Anteil der Tests durch den neuen Dienst herausgefiltert wird, und keine Zahlen zur Latenz nach der Neufassung genannt. Wie viel Geld dadurch gespart wurde, lässt sich aus den öffentlichen Angaben nicht ableiten.
Klar erkennbar ist aber, von welchem Glied der Kette sich der Druck zum nächsten verschiebt. Im April dieses Jahres stoppte GitHub die Neuanmeldung für die kostenpflichtigen Einzelpläne von Copilot, mit der Begründung, der Rechenaufwand lang laufender Agenten-Aufgaben übersteige das, wofür die Tarife ausgelegt seien. Noch früher hatte eine Flut von KI-generierten Commits GitHub bereits in Ausfälle getrieben, und Microsoft musste zeitweise Kapazität von AWS ausleihen, um standzuhalten. Drei unterschiedliche Vorfälle, doch sie zeigen dasselbe: Zuerst beschleunigt sich die Codegenerierung, dann das Review, und danach trifft es der Reihe nach jedes System, dessen Kapazität für die Geschwindigkeit menschlicher Programmierer ausgelegt wurde. Test Impact Analysis ist in dieser Runde nur der Dienst, der als Erstes Alarm geschlagen hat.
Quellen: CocoLoop, Anthropic Engineering-Blog; die Vervielfachungen bei Code-Ausstoß, Tests und CI-Jobs sowie die Gültigkeitsdauer der drei Notlösungen stammen aus den dort veröffentlichten Angaben.