Anthropic hat gestern einen Erfahrungsbericht aus dem eigenen Maschinenraum veröffentlicht, und der ist konkreter als die meisten Blogposts über KI und Entwicklung. Sachin Malhotra beschreibt, wie der Dienst, der entscheidet welche Tests bei welchem Pull Request laufen, dreimal fast zusammengebrochen ist.
Die Zahlen vorweg
Anthropic-Entwickler liefern pro Quartal im Schnitt das Achtfache an Code aus, verglichen mit den Jahren 2021 bis 2025. Claude schreibt 80 Prozent davon und prüft und genehmigt einen großen Teil der Pull Requests gleich mit. Die Zahl der Tests im Code ist auf das Zehnfache gewachsen, die Zahl der Entwickler kaum. Ergebnis: 25-mal so viele CI-Jobs, innerhalb von sechs Monaten.
Malhotras Beobachtung dazu: Code schreiben ist nicht mehr der Engpass. Sobald auch das Review schneller wird, spürt es die CI.
Was der Dienst überhaupt tut
Jeden Test bei jeder Änderung laufen zu lassen, funktioniert bis zu einer gewissen Größe. Danach werden die CI-Gates lang, teuer und unglaubwürdig. Anthropic wählt deshalb aus: Ein «Listener» schreibt die Testergebnisse jedes CI-Laufs mit, ein «Selector» entscheidet daraus, welche Tests bei einem neuen PR laufen.
Interessantes Detail am Rande: Menschen erkennen ganz gut, welcher fehlgeschlagene Test sie nichts angeht. Agenten brauchen dafür Kontext. Bekommen sie stattdessen eine saubere, passende Testmenge, prüfen sie sich selbst und arbeiten schneller weiter.
Der Haken: Die Historie pro Test lag in einem einzigen Prozess, also gab es genau einen Schreiber, und der ließ sich nicht aufteilen. Bei mehreren CI-Jobs pro Sekunde fiel der Listener zurück. 20 Minuten Rückstand bedeuteten zehntausende nicht eingespielte Testergebnisse.
70 Tage, 29 Tage, weniger als ein Tag
Im Oktober fing das Piepen an. Flicken eins: doppelt so viele Kerne. Hielt 70 Tage.
Zwischendurch hat Malhotra eine Dauersession in einer internen Fassung von Claude Tag laufen lassen, die den Dienst überwacht hat. Sobald der Rückstand über 50.000 Jobs ging, hat Claude ihn angepingt und das Gespräch dort fortgesetzt, wo es aufgehört hatte. Claude hat monatelang für den Umbau plädiert. Man hat sich monatelang für den nächsten Flicken entschieden.
Flicken zwei, im Februar: ein Shard pro Paket statt eines Schreibers für alles. Hielt 29 Tage. Flicken drei, im März: tägliche Neustarts. Hielt keinen Tag, und der Dienst fiel dabei immer weiter zurück.
Der Umbau
Dann doch Claudes Vorschlag: ein In-Memory-Datenspeicher. Jeder Listener-Worker hängt sein Ergebnis an ein Journal und ist fertig, ohne etwas im Speicher zu halten. Ein eigener Prozess rollt das Journal alle paar Sekunden zur Historie pro Test zusammen. Der Prozess hält keinen Zustand mehr, also kann man ihn beliebig in die Breite ziehen. Teurer im Betrieb, dafür messbar.
Drei Wochen, ein Entwickler. Vor einem Jahr wäre das eher ein Quartal gewesen. Seitdem ist die Warteschlange flach.
Plant für das 25-Fache
Malhotras Rat steht am Ende des Textes und ist der Grund, warum ich ihn hier verlinke: Geht davon aus, dass eure Architektur in zwei Quartalen beim 25-Fachen liegt. «Over-engineering» als Vorwurf verliert gerade an Kraft, weil die Latte höher wandert. Das Zehn- bis Zwanzigfache der gefühlten Last darf ins v0-Design, solange das Budget es hergibt.
Was mich daran am meisten beschäftigt: Der eigentliche Fehler war nicht die Architektur. Der Fehler war, dreimal das Billige zu nehmen, obwohl der Assistent daneben stand und den Umbau vorgeschlagen hat. Umbauen kostet inzwischen einen Bruchteil dessen, was es mal gekostet hat. Flicken kostet unverändert viel Aufmerksamkeit.
Quellen: