Beim Claude-Code-Team prüfen über­wie­gend Maschinen den Code, der Anteil zurück­ge­nom­mener Ände­rungen sank um über 40 Prozent

Anthropic beschreibt, wie das Team hinter Claude Code einen Code prüft, den es zum größten Teil nicht mehr selbst schreibt: Nach Angaben des Teams stammen etwa 90 Prozent des Codes von Claude Code aus Claude. Von Juni bis September hat sich die Zahl der übernommenen Pull Requests mehr als verdoppelt, und der Anteil, der wieder zurückgenommen werden musste, sank um mehr als 40 Prozent. Im großen Sammel-Repository von Anthropic stieg die Zahl der Änderungen am Tag von etwa zwei­ein­halb­tau­send im Mai auf über dreißigtausend im September. Claude Code liegt in einem eigenen Repository, steht aber unter demselben Druck. Bei dieser Menge liest niemand mehr jede Zeile von Hand.

Die Frage hinter dem Lesen jeder Zeile

Naheliegend wäre der Schluss, die Prüfung sei damit dünner geworden und die gesunkene Rücknahmequote ein glücklicher Zufall. Das Team beschreibt einen Umbau. Bisher galt, dass Code sicher ist, wenn vor der Übernahme ein Mensch jede Zeile gelesen hat. Die Prüfung stand dafür als Tor am Ende: Code schreiben, Pull Request öffnen, auf eine Kollegin warten. Das Team hält die Frage, ob ein Mensch den Code gelesen hat, für einen ungenauen Ersatz für die eigentliche: was an dieser Änderung schiefgehen kann und welche Prüfung, maschinell oder menschlich, das am ehesten findet. Mit dieser Frage verschiebt sich auch der Zeitpunkt. Geprüft wird laufend, ähnlich einer Recht­schreib­prü­fung beim Schreiben, und die meisten Änderungen hat Claude mindestens einmal geprüft und korrigiert, bevor eine Person sie ansieht.

Sechs Schichten und die Rücknahme darunter

Vor dem Pull Request lässt Claude Tests, Build und Linter laufen und muss die Ausgabe vorzeigen, statt bloß den Abschluss zu melden. Ein Subagent liest den Diff danach mit frischem Kontext. Boris Cherny, der Claude Code entwickelt hat, schätzt, dass diese Möglichkeit zur Selbstprüfung das Ergebnis zwei- bis dreimal besser macht. Auf jedem Pull Request folgen Pflichtprüfungen (Lint, Typen, Tests auf allen Plattformen, Build), eine Prüfung durch Claude und eine getrennte Sicher­heits­prü­fung. Bei der Prüfung durch Claude suchen mehrere Agenten gleichzeitig nach Fehlern, eine zweite Gruppe stimmt über jeden Fund ab, und erst bei genug Zustimmung erscheint er als Kommentar, nach Schwere geordnet; reine Stilfragen fallen vorher heraus. Seit der For­schungs­vor­schau dieser Prüfung stieg der Anteil interner Pull Requests mit inhaltlichen Kommentaren von 16 auf 54 Prozent. Ein offener Fund aus Fehler- oder Sicher­heits­prü­fung hält die Übernahme an, bis er behoben oder mit Begründung geschlossen ist. Danach prüft eine Merge-Queue jede Änderung noch einmal gegen den aktuellen Hauptzweig, neues Verhalten geht hinter einem Schalter zuerst an Beschäftigte von Anthropic und öffentlich zuerst in den Kanal latest, dem der stabile Kanal folgt. Jede Schicht übersieht etwas, durch alle zusammen kommt wenig, und für den Rest gibt es die schnelle Rücknahme: Schalter lassen sich ohne neue Auslieferung abstellen, defekte Builds werden zurückgenommen.

Die Stufe setzt die Änderung

Was ein Mensch noch tut, richtet sich nach dem Risiko. Ein Klassifikator liest die Änderung und ordnet sie einer von drei Stufen zu. Dokumentation, Texte und zusätzliche Funktionen hinter einem Schalter gehen ohne menschliche Freigabe durch, sobald die automatischen Prüfungen grün sind. Gewöhnliche Produktänderungen und Eingriffe in heikle Bereiche wie Caching, Auto-Updater oder Systemprompts brauchen eine Person, der riskanteste Code zwei. Ein zweiter Klassifikator fragt, ob eine Änderung trotz niedriger Stufe eine weitere Person braucht, und Workflow-Dateien der CI sowie von den Verantwortlichen als heikel gelistete Pfade brauchen immer einen Menschen. Die leichteren Wege stehen allein Autoren auf der Vertrauensliste des Repositorys offen, meist dem Team, dem es gehört. Die Freigabe eines Agenten zählt nie als die einer Person. Wer den Agenten angeleitet hat, gilt als einer der vorgeschriebenen Prüfer, so als hätte diese Person den Code selbst getippt. Eine Freigabe gilt außerdem für genau einen Commit: Kommt ein Push eines Agenten oder ein von Hand aufgelöster Merge hinzu, muss sie neu erteilt werden.

Damit gilt jetzt eine andere Rechnung. Das Ziel lautet, dass die meisten Pull Requests mit höchstens einem Menschen übernommen werden, der auch der Autor sein darf. Gemessen wird menschliche Zeit: Freigaben je Pull Request im Median und im 95. Perzentil, Kommentare und die Wartezeit auf eine Person. Rücknahmen und Vorfälle sind die Leitplanke, denn zur Zeit der Prüfung gehört auch die Zeit, in der Menschen reparieren, was schlechter Code kaputt macht. Steigen diese Zahlen, wäre die Zeit bloß verschoben.

Die Bremse fehlt noch

Offen bleibt, wer eine schlechte Übernahme bemerkt. Das hängt weiterhin am Autor, am wöchentlich wechselnden Bereit­schafts­dienst und an den Übersichten für Rücknahmen und Vorfälle. Automatische Bremsen, die bei steigenden Zahlen die Freigaben verschärfen, gibt es noch nicht, und die Ingenieure des Teams wollen sie haben, bevor mehr Code ganz ohne Menschen übernommen wird. Die Zahlen stammen vom Team selbst und gelten für sein eigenes Repository; welchen Anteil an den gesunkenen Rücknahmen welche Schicht hat, schlüsselt der Beitrag nicht auf. Ein Kollege hält fest, dass langsameres Arbeiten die Fehlerrate zwar senkt, vor allem aber, weil dann von allem weniger geschieht. Das Team setzt deshalb auf schnelleres Erkennen und Beheben.