Wie das Claude Code-Team Code Reviews durchführt: sieben Schritte und keine Circuit Breaker

Am 15. Oktober 2026 veröffentlichte das Claude-Code-Team seine eigene Darstellung, wie es Code überprüft, einen vierzehnminütigen Engineering-Beitrag, der Addy Osmani, Morgan Westlee Lunt und Qing Wang zugeschrieben wird. Der Satz, der erklärt, warum überhaupt jemand danach sucht, kommt früh: Claude schreibt etwa 90 Prozent von Claude Codes eigenem Code. Der Beitrag ist keine Verteidigung dieser Zahl, sondern eine Beschreibung der Maschinerie, die darunter vorhanden sein musste, bevor das Ganze überlebensfähig war, und die Teile, die es wert sind, genau gelesen zu werden, sind die, die noch fehlen.

Die meisten Zusammenfassungen bleiben bei den beiden Schlagzeilen-Zahlen stehen: Die Zahl der gemergten Pull Requests in der Codebasis von Claude Code hat sich zwischen Juni und September 2026 mehr als verdoppelt, während der Anteil, der zurückgerollt werden musste, um mehr als 40 Prozent sank. Beide stammen vom Team selbst, und beide lassen sich durch mehrere unterschiedliche Vorgehensweisen erzeugen, einschließlich der, die man vermutet, nämlich dass die Review stillschweigend abgeschafft wurde. Der Beitrag sagt, das sei nicht der Fall. Sie verlagerten den Großteil des Lesens auf Maschinen, optimierten auf menschliche Zeit und Aufmerksamkeit hin und investierten darin, Fehler schnell und einfach rückgängig machen zu können. Alles andere ist das Detail des Wie.

Warum die Überprüfung überhaupt erst zum Engpass wurde

Der Druck kam nicht von einer Grundsatzentscheidung. Er kam von der Menge. In Anthropics Monorepo, so berichtet der Beitrag, stieg die Zahl der täglich eingehenden Änderungen von etwa 2.500 im Mai auf mehr als 30.000 im September 2026. Claude Code liegt in einem eigenen Repository, getrennt von diesem Monorepo, steht aber in kleinerem Maßstab unter demselben Druck.

Bei diesem Tempo, räumt der Beitrag ein, sei eine manuelle Zeile-für-Zeile-Prüfung unglaublich schwierig, wenn nicht unmöglich. Niemand dort behauptet, dass es unnötig sei, dass ein Mensch jeden Diff liest. Sie behaupten, dass es nicht mehr skaliert, jeden Diff zu lesen, und dass „hat ein Mensch den Code gelesen“ schon immer ein ungenauer Stellvertreter für die entscheidende Frage war: Was könnte bei dieser Änderung schiefgehen, und welche Prüfung, automatisiert oder menschlich, ist die richtige, um es zu erkennen.

So formuliert verschiebt sich das Tor. Die Überprüfung ist kein Tor am Ende des Weges mehr, sondern wird kontinuierlich, eher wie eine Rechtschreibprüfung beim Schreiben. Die meisten Änderungen wurden von Claude gelesen und korrigiert, bevor ein Mensch einen Blick darauf wirft.

Worauf sie optimiert haben und was als Misserfolg gilt

Das erklärte Ziel ist, dass die meisten Pull Requests in den Claude-Code-Repositories – die der Beitrag als CLI, Desktop- und Web-Apps sowie Mobile-Apps beschreibt – mit höchstens einem Menschen im Loop zusammengeführt werden, der der Autor sein kann, ohne Zunahme von Reverts oder Incidents. Der dritte Punkt ist es, der daraus ein echtes Ziel statt einer Kostensenkungsübung macht.

Sie messen menschliche Zeit auf beiden Seiten der Bilanz: die Zeit, die Menschen mit dem Reviewen verbringen, und die Zeit, die sie damit verbringen, zu beheben, was schlechter Code kaputt macht. Die erste zu senken hilft nicht, wenn die Kosten auf der zweiten Seite wieder auftauchen, und das Team sagt das direkt. Die erfassten Zahlen sind also menschliche Freigaben pro Pull Request, angegeben als Median und 95. Perzentil, menschliche Kommentare und wie lange ein Pull Request auf eine Person wartet. Revert- und Incident-Raten liegen als Schutzgeländer unter all dem: Wenn diese steigen, wurde keine menschliche Zeit gespart, sondern nur verlagert.

Review-Kosten-Kennzahlen lassen sich isoliert leicht manipulieren; ein Prüfer, der alles genehmigt, erzeugt wunderschöne Diagramme zur Genehmigungsdauer. Die Leitplanke ist das, was verhindert, dass das Diagramm lügt.

Sieben Schritte, nicht ein einziges Tor

Der Beitrag stellt den Weg einer typischen Änderung als sieben nummerierte Schritte dar. Jede Ebene erkennt einige Probleme und übersieht andere, und kostengünstigere Prüfungen finden vor teureren statt.

• Verifikation, bevor der Pull Request existiert. Claude führt die Tests, den Build und den Linter aus, und ein zweiter Agent prüft den Diff in einem frischen Kontext. Viele Entwickler setzen außerdem interne Skills ein: Einer sucht nach Bugs, einer vereinfacht den Diff, einer prüft das Verhalten End-to-End. Boris Cherny, der Claude Code entwickelt hat, hat es als wahrscheinlich wichtigste Sache für gute Ergebnisse bezeichnet, Claude eine Möglichkeit zu geben, seine eigene Arbeit zu verifizieren, und schätzt, dass es das Endergebnis zwei- bis dreimal besser macht.

• KI-Review für jeden Pull Request. Ein Claude-Review liest den Diff vor dem Hintergrund des gesamten Repositorys und der im Pull Request angegebenen Absicht. Mehrere Agenten suchen parallel nach Fehlern, anschließend stimmt eine separate Gruppe über jeden Fund ab, und dieser wird nur gepostet, wenn genügend Stimmen ihn als echt bestätigen. Funde zu Stil, Diagnose oder Aufräumarbeiten werden verworfen. Was übrig bleibt, erscheint als Inline-Kommentar mit dem Tag Important, Nit oder Pre-existing. Als die Research Preview startete, stieg der Anteil interner Pull Requests mit substanziellen Review-Kommentaren von 16 Prozent auf 54 Prozent. Admins legen für jedes Repository Quick, Standard oder Deep fest.

• Sicherheitsüberprüfung. Ein separater automatisierter Durchlauf. Ein Pull Request kann nicht zusammengeführt werden, solange ein Befund aus einer der beiden Überprüfungen offen ist; du behebst ihn oder schließt den Thread mit einer kurzen Begründung. Dieselbe Prüfung ist öffentlich verfügbar – als Open-Source-GitHub Action für die Sicherheitsüberprüfung oder als Befehl /security-review.

• Automatisierte Prüfungen, die blockieren. Lint, Typprüfungen, Tests auf jeder Plattform und ein Build.

• Menschliche Genehmigung, nach Risiko abgestuft. Ein Klassifikator liest die Änderung und legt die Stufe fest, statt dass der Autor sie festlegt. Dieser Schritt bekommt unten einen eigenen Abschnitt, denn hier steckt der größte Teil des interessanten Designs.

• Merge-Queue, Flags und schrittweise Veröffentlichung. Die Warteschlange führt jeden Check erneut gegen main aus, nachdem die Änderung angewendet wurde, sodass zwei Pull Requests, die jeweils für sich bestehen, nicht zu einem defekten main kombiniert werden können. Neues Verhalten wird zunächst hinter einem Flag für Anthropic-Mitarbeitende ausgeliefert, dann an den Latest-Kanal, wobei stable nachfolgt.

• Schnelle Erkennung und Rollback. Flags lassen sich ohne Deploy abschalten, es gibt eine wöchentliche On-Call-Rotation, und in Incident-Reviews wird gefragt, welche Ebene das Problem hätte abfangen sollen. Manche Fehler kommen trotzdem durch, deshalb geht es in der letzten Ebene darum, sie schnell zu bemerken statt sie zu verhindern.

Die Änderung legt die Stufe fest, nicht den Autor.

Ein Docs-Fix und eine Änderung am Auto-Updater bergen nicht dasselbe Risiko, also erhalten sie nicht dasselbe Review. Die Tabelle im Beitrag hat drei Stufen, und jede beantwortet eine einzige Frage: Wie viele Personen – falls überhaupt jemand – müssen dies genehmigen, bevor es gemergt wird.

Niedrig umfasst Dokumentation, Texte, rein interne Funktionen und additive Änderungen hinter einem Flag; sobald automatisierte Prüfung und Sicherheit grün sind, ist keine Person erforderlich. Mittel umfasst gewöhnliche Produktänderungen sowie sensible Bereiche wie Caching, den Auto-Updater und System-Prompts und erfordert eine Person. Hoch umfasst den Code mit dem höchsten Risiko und eine kleine Gruppe von Pfaden, die immer zwei Personen erfordern.

Der Klassifikator macht nur die Hälfte des Designs aus. Ein zweiter Klassifikator fragt, ob diese konkrete Änderung eine weitere Person benötigt, selbst wenn ihre Stufe sagt, dass sie es nicht tut. Manche Pfade benötigen unabhängig von der Stufe immer eine Person: alles, was die Eigentümer als sensibel eingestuft haben, und jede CI-Workflow-Datei. Nur Autoren auf der Vertrauensliste des Repositorys, zumeist das Eigentümerteam, erhalten die leichteren Pfade; alle anderen benötigen eine zweite Person. Die Genehmigung eines Agenten zählt niemals als die einer Person, daher kann eine automatisierte Prüfung eine Änderung mit geringem Risiko freigeben, aber keinen Platz besetzen, der einen Menschen erfordert. Wer die Änderung angestoßen hat, ist dafür verantwortlich. Und eine Genehmigung gilt für einen bestimmten Commit, daher benötigt ein neuer Commit, einschließlich eines Pushs durch einen Agenten oder eines manuell aufgelösten Merges, erneut die Genehmigung.

Zwei Details sind es wert, übernommen zu werden, selbst wenn man nie einen Klassifikator baut. Die Stufe ergibt sich aus der Änderung, nicht aus dem Autor, und Vertrauen ist ein separates, engeres Gate obendrauf. Und eine Freigabe ist an einen Commit gebunden statt an einen Pull Request, was die häufigste Lücke in Review-Systemen schließt: ein grüner Haken, früh in einem Branch verdient, für Code ausgegeben, den niemand angesehen hat.

Der Reviewer wird anhand seiner eigenen Vorfälle geschult.

Dies ist der Teil, den die meisten Berichte überspringen, und er erklärt, warum die Vereinbarung weiterhin funktioniert, statt abzudriften.

Das Team sammelte vergangene Pull Requests, die Vorfälle verursacht hatten, zusammen mit ihren Fix-Forwards und Reverts, und ließ Ingenieure, die diesen Code kennen, jeden Bug und seinen Ort bestätigen. Diese Sammlung ist heute ein Eval. Der Reviewer läuft täglich dagegen. Wenn sich seine Prompts, Tools oder sein Modell ändern, muss die Änderung den gesamten Satz überstehen: behalten, wenn die Bewertung steigt, verwerfen, wenn nicht. Ihre Fehler wurden zur Testsuite für das, was ihre Fehler eigentlich abfangen soll.

Das ist eine andere Haltung als beim Optimieren eines Linters, der an einem festen Regelsatz gemessen wird. Dieser Reviewer wird an den konkreten Arten und Weisen gemessen, wie diese Codebasis bereits kaputtgegangen ist, sodass die Eval mit jedem Fehler wächst. In nichts, was Anthropic veröffentlicht hat und was wir gelesen haben, taucht eine Punktzahl dafür auf, und der Beitrag behauptet nicht, dass der Reviewer fertig ist.

Die Ebene, die noch nicht erstellt wurde

Hier ist das Eingeständnis, das den Beitrag glaubwürdig macht. Alles oben beschreibt ein System, das Fehler erkennt und rückgängig macht, nicht eines, das bemerkt, dass sich seine eigene Fehlerrate ändert. Das Team hat noch keine Circuit Breaker, die die Freigabe automatisch verschärfen, wenn sich Revert- oder Incident-Zahlen bewegen, und die Ingenieure dort wollen sie, bevor mehr Code auf Merges ohne menschliches Zutun umgestellt wird.

Was es stattdessen gibt, ist das Bemerken durch Menschen. Flags werden ohne Deploy abgeschaltet, die wöchentliche On-Call-Rotation behält alles im Blick, und Incident-Reviews fragen, welche Ebene das Problem hätte erkennen sollen. Der Ausspruch eines Kollegen ist der nützlichste Satz für alle, die einen ähnlichen Rollout planen: Langsamer zu werden senkt tatsächlich deine Fehlerquote, aber vor allem, weil du von allem weniger machst. Das Team wäre lieber schneller darin, Probleme zu bemerken und zu beheben, als langsamer darin, sie zu erzeugen.

Lesen Sie die sieben Schritte mit diesem Gedanken noch einmal. Sechs entscheiden, ob eine Änderung weitergeht. Der siebte ist eine Reihe von Gewohnheiten, um es im Nachhinein zu bemerken. Es gibt keine Rückkopplungsschleife, die vom Ergebnis zurück in die Freigabeinstanz führt, und die Menschen, die das System gebaut haben, sagen das selbst.

Die zweite Aufgabe von Review, die der Beitrag weitgehend ausklammert

Der Beitrag macht deutlich, dass Code-Review zwei Aufgaben erfüllt: Probleme finden und beheben, bevor sie ausgeliefert werden, und gemeinsamen Kontext im Team aufbauen. Er konzentriert sich auf die erste und kommt dann mit einer ungewöhnlich ehrlichen Antwort auf die zweite zurück: Es gibt dafür keinen formalen Prozess, niemand hat ein vollständiges mentales Modell von Claude Code im Kopf, und sie glauben nicht, dass das jemand braucht. Sie wollen einen Teil der Codebasis verstehen? Bitten Sie Claude um eine Erklärung genau dieses Ausschnitts.

Zwei Anweisungsdateien enthalten den Kontext, der früher nur in den Köpfen der Reviewer lebte. CLAUDE.md sagt Claude, was das Projekt ist, welcher Stack verwendet wird, welche Konventionen gelten, welche Ziele und Nicht-Ziele es gibt – bewusst kurz gehalten. REVIEW.md wird von Code-Ownern geschrieben und beschreibt, wie Fehler in ihrem Teil des Codes aussehen, welche Pfade zu überspringen sind, und verlangt eine Datei- und Zeilenangabe statt einer Vermutung.

Verantwortlichkeit bekommt eine eigene Regel: Du bringst den Change rein, du verantwortest ihn. Wenn du eine kleine oder mittlere Änderung mergst und etwas schiefgeht, ist die Norm, dass du es behebst. Das funktioniert, weil Änderungen klein sind, weil Flags und Reverts die meisten Fehler in Minuten rückgängig machen und weil der Blast Radius die Messlatte dafür setzt, wie viele Prüfungen eine Änderung bekommt. Es ist eine Norm, die auf der Genehmigungsregel aufsetzt, kein Ersatz für sie.

Wo ein Router passt – und wo nicht

Die oben beschriebene Pipeline ist eine Pipeline von Modellaufrufen: ein Review-Agent, der einen Diff gegen ein gesamtes Repository liest, mehrere parallel laufende Bug-Hunting-Agenten, eine Gruppe, die über jeden Fund abstimmt, ein Sicherheitsdurchlauf und der Reviewer, der täglich gegen eine wachsende Eval erneut ausgeführt wird. Das ist ein Routing-Problem, bevor es ein Review-Problem ist, denn ein Anbieter, der einen schlechten Nachmittag hat, sollte keine Merge-Queue zum Stillstand bringen.

OrcaRouter ist ein OpenAI-kompatibler Endpunkt für mehr als 200 Modelle mit einem einzigen Schlüssel, mit automatischem Failover über Anbieter hinweg und ohne Aufschlag, d. h. der Listenpreis des Anbieters wird eins zu eins weitergegeben. Teams, die ihre eigene Version dieser Pipeline betreiben, erhalten eine einzige Abrechnungsbeziehung und eine einzige Stelle, an der sie ein Modell wechseln können, wenn sich die Qualität eines Reviewers ändert – genau das, wofür die tägliche Evaluierung konzipiert ist.

Die Grenze ist wichtig. Wir hosten Modelle. Wir hosten nicht Claude Code, wir führen kein Code Review für Claude Code aus, und wir haben keinen Zugriff auf die Pipeline, um die es in diesem Artikel geht. Code Review für Claude Code ist ein Produkt von Anthropic, allgemein verfügbar in den Tarifen Team und Enterprise, mit einer leichteren Version, die lokal als /code-review verfügbar ist. Wenn du diese Pipeline willst, dort ist sie zu finden; in der Version deines eigenen Teams ist ein Router eine Infrastrukturentscheidung, keine Review-Entscheidung.

Was ein kleineres Team tatsächlich nachahmen kann

Schreibe die Review-Regeln dort auf, wo der Reviewer sie lesen kann: eine kurze CLAUDE.md für das Projekt und eine REVIEW.md pro Bereich, die benennt, wie ein Fehler aussieht, und statt einer Vermutung eine Datei und Zeile verlangt. Schreibe die Risikostufen auf, mache sie zu einer Eigenschaft der Änderung statt des Autors, beginne streng und lockere nur mit Belegen. Begrenze, was automatisierte Reviews genehmigen können, und lass niemals zu, dass die Genehmigung eines Agenten als die einer Person zählt. Binde Genehmigungen an Commits. Betreibe die Merge-Queue. Verwandle Vorfälle und Reverts in Testfälle und bewerte den Reviewer neu, wann immer du ihn änderst, denn ein nicht gemessener Reviewer ist ein Linter mit besserem Marketing.

Dann achten Sie auf die Leitplanke, nicht auf die Genehmigungszeit. Die eigene Formulierung des Teams liefert Ihnen den Test für jede Review-Änderung, die Sie erwägen: Blieben die Revert- und Incident-Raten stabil, oder verlagerte sich die Zeit einfach vom Reviewer zu der Person, die danach aufräumt? Diese Frage lässt sich mit Daten beantworten, die die meisten Teams bereits haben, und sie unterscheidet einen Prozess, der schneller geworden ist, von einem, der nur für ein Quartal schneller wirkt.