Claude Code Review ist GA: die Review-Schichten drumherum und welche du ohne Team-Plan übernehmen kannst

Claude Code Review hat am 15. Oktober die Research Preview für Team- und Enterprise-Pläne verlassen. Am selben Tag hat das Claude-Code-Team veröffentlicht, wie das eigene Repository reviewt wird, und dort ist der Managed Reviewer eine von sieben Schichten. Die meisten anderen sind GitHub-Einstellungen und schriftliche Regeln, die jeder Plan übernehmen kann.

Eine Sache lässt sich nicht übernehmen, und um die geht es hier. Der Managed Service liest seine Review-Regeln, REVIEW.md, aus dem Base Branch, nie aus dem Pull Request. Der lokale Befehl /code-review liest REVIEW.md offiziell gar nicht. In meinen Läufen auf Claude Code 2.1.302 hat er die Datei trotzdem gelesen, von der Platte, auch eine Kopie, die der geprüfte Change gerade bearbeitet hatte. Ob die Regeln danach hielten, hing vom Modell ab.

Was unten zum Managed Service steht, stammt aus der Doku und der Ankündigung; ausprobiert habe ich ihn nicht. Den lokalen Befehl habe ich getestet, elfmal.

Was steckt in Claude Code Review GA?

Eine GitHub App, die Pull Requests auf Anthropics Infrastruktur reviewt, für Team- und Enterprise-Organisationen. Ein Owner schaltet sie ein, installiert die App und wählt Repositories aus. Jedes Repository bekommt eine Stufe (Quick, Standard oder Deep) und einen Trigger: einmal beim Öffnen des PR, nach jedem Push oder nur, wenn jemand mit Schreibrechten @claude review kommentiert.

Laut Ankündigung sind die meisten Reviews jetzt in 6 bis 10 Minuten fertig, in der Preview waren es rund 20. Die Preview-Doku nannte im Schnitt 15 bis 25 Dollar pro Review; die Kostenseite zum GA nennt gar keinen Betrag pro Review mehr. Abgerechnet wird nach Token-Verbrauch über Usage Credits, getrennt vom Plan, und der Preis wächst mit der Stufe, der Größe des Changes und der Zahl der Kandidaten-Findings, die geprüft werden müssen. Ein Repository, das über die Admin-Seite hinzukommt, startet mit „After every push“, dem Trigger mit den meisten Reviews. Setz also zuerst das monatliche Ausgabenlimit. Berechtigte Enterprise-Organisationen können bis zum 15. Januar 2027 mindestens 10.000 Dollar an Credits abrufen; sie verfallen 30 Tage nach dem Abruf.

Zwei Grenzen wiegen schwerer als der Preis. Ein Review liest Code und baut oder startet ihn nie. Und es genehmigt oder blockiert nie: Laut Doku endet sein Check Run nicht als Fehlschlag („doesn’t conclude as a failure“). Organisationen mit Zero Data Retention, der HIPAA-Konfiguration oder kundenverwalteten Schlüsseln können es nicht nutzen.

Welche Review-Schichten legt das Claude-Code-Team um Code Review?

Sieben, von vor dem PR bis nach dem Merge. Vor dem PR lässt Claude Tests, Build und Linter laufen, und ein zweiter Agent reviewt den Diff in einem frischen Kontext. Auf jedem PR: Pflicht-CI, das AI-Review, ein separates Security Review und eine Approval-Stufe (kein Mensch, einer oder zwei), die ein Klassifikator wählt, während ein zweiter Klassifikator fragt, ob der Change trotzdem einen Menschen braucht. Danach eine Merge Queue, die die Checks gegen den neuesten main erneut laufen lässt, neues Verhalten hinter Flags, die zuerst intern genutzt werden, gestaffelte Releases und ein schnelles Rollback.

Das meiste Gewicht tragen die Regeln um die Schichten herum. Jedes Finding bekommt eine Antwort, wird behoben oder mit Begründung geschlossen, und ein offenes Bug- oder Security-Finding blockiert den Merge. Nur vertrauenswürdige Autoren, meist das zuständige Team, bekommen die leichteren Approval-Wege, und manche Pfade brauchen immer einen Menschen. Das Approval eines Agenten besetzt nie einen menschlichen Platz. Wer einen Agenten zu einem PR angestoßen hat, zählt als Pflicht-Reviewer. Ein Approval gilt für einen bestimmten Commit.

Die Zahlen sind intern und von außen nicht prüfbar. PRs mit „substanziellen“ Review-Kommentaren stiegen mit dem Start der Preview von 16 % auf 54 %, und der Beitrag definiert „substanziell“ nicht. Nach der unten beschriebenen Arbeit an der Konvergenz stieg der Anteil der PRs, die in einer Review-Runde durchgehen, von 65 % auf 78 %. Der Beitrag benennt auch seine eigene Lücke: Noch verschärft nichts die Approval-Regeln automatisch, wenn sich Revert- oder Incident-Zahlen bewegen.

Welche Schichten von Claude Code Review funktionieren ohne Team-Plan?

Alle außer dem Managed Reviewer selbst und den internen Klassifikatoren des Teams.

Die Zeile zum Blockieren verdient einen zweiten Blick. Selbst das Managed-Produkt blockiert nicht. Das „kein Merge mit offenem Finding“ des Teams kommt daher, dass jeder Review-Thread vor dem Merge aufgelöst sein muss, eine Repository-Einstellung, die der Beitrag empfiehlt. Der Reviewer schreibt nur Text, und eine Branch-Regel macht diesen Text verbindlich. Das ist die Trennung aus Ein Prompt ist keine Invariante: Eine Anweisung hält meistens, ein Check, den die Plattform ausführt, hält auf jedem Pfad, den er abdeckt. Und dieser Check deckt weniger ab, als es scheint. Ein aufgelöster Thread braucht weder Fix noch Begründung, und ein Review, das aus Budgetgründen übersprungen oder auf einem Draft nie gestartet wurde, hinterlässt keinen Thread zum Auflösen. Branch Protection auf privaten Repositories braucht außerdem einen bezahlten GitHub-Plan.

Eine Namensfalle, wenn du schon in der Doku bist: /code-review läuft „as a forked subagent“. Gemeint ist die Skill-Einstellung context: fork, von der die Skills-Seite sagt, sie laufe nicht in einem Fork der aktuellen Konversation („doesn’t run in a fork of the current conversation“). Der Reviewer sieht deine Session nicht, und das ist für einen Reviewer richtig, aus den Gründen in Dein geforkter Subagent weiß schon zu viel. Der Konversations-Fork, der alles erbt, ist ein anderes Feature mit fast demselben Namen.

Wie lässt du lokales /code-review auf einem Branch oder einem Bereich laufen?

Gib ihm ein Ziel. Ohne Ziel reviewt es die Commits deines Branches, die dem Upstream voraus sind, plus nicht committete Änderungen; ohne Upstream weicht es auf main oder den vorherigen Commit aus. Am Claude-Code-Prompt:

/code-review main...my-feature
/code-review a1b2c3d..HEAD
/code-review --comment 1234
/code-review --fix

Das Erste vergleicht einen Branch mit main. Das Zweite reviewt nur Commits nach a1b2c3d, das günstige Re-Review nach einem vollen Durchgang. --comment postet die Findings als Inline-Kommentare in PR 1234. --fix wendet sie über deinen Permission-Modus auf den Working Tree an; in einer interaktiven Session läuft das Review im Hintergrund, deshalb macht /rewind seine Änderungen an Dateien, die du nicht angefasst hattest, nicht rückgängig, git schon. Aus einer Shell läuft derselbe Befehl im Vordergrund:

claude -p "/code-review a1b2c3d..HEAD"

Eine Stufe vor dem Ziel (low bis max) tauscht Konfidenz gegen Abdeckung: low meldet nur, worin es sich am sichersten ist. Interaktiv wird eine eingetippte Stufe für spätere Läufe gemerkt; eine Stufe, die mit -p übergeben wird, nicht.

Liest lokales /code-review die REVIEW.md?

Nicht als Konfiguration, und die Doku sagt das auch: Der Befehl folgt deiner CLAUDE.md („follows your CLAUDE.md“) und liest REVIEW.md nicht („doesn’t read REVIEW.md“). In der Praxis hat jeder meiner Läufe, in dem die Datei existierte, sie trotzdem gelesen.

Der Aufbau war ein Scratch-Repository mit einem Commit, der eine Paginierungsfunktion mit Off-by-one, einem verirrten print() und ohne Docstring hinzufügt. CLAUDE.md verbot print() in Bibliothekscode. REVIEW.md sagte, ein fehlender Docstring an einer neuen öffentlichen Funktion sei Important, kein Nit. Jeder Lauf sah so aus:

claude -p "/code-review medium HEAD~1..HEAD" \
  --allowedTools "Bash(git:*)" Read Grep Glob

Drei Details dazu, wie das lief, sind wichtig für alle, die es wiederholen. Das Session-Modell war Opus 5.5. Meine User-Settings umgehen Permission-Abfragen, also hat --allowedTools nichts eingeschränkt, und nur deshalb liefen die cat-Aufrufe des Reviewers: In einem Standard-Setup würde ein cat außerhalb von Bash(git:*) an einer Abfrage hängen bleiben. Und obwohl ich medium übergeben habe, steht in den Traces im Prompt des Reviews selbst „high effort“. Elf Läufe kosteten etwa 2,31 Dollar.

Das Off-by-one kam in allen elf zurück. Die beiden Regeln erwiesen sich als schwache Sonde: Ein Basislauf ganz ohne Regeldateien meldete print() und den Docstring trotzdem, als gewöhnliche Findings. Dass ein Finding auftaucht, beweist hier also nichts. Es zählt, woher es kommt.

Mit vorhandener REVIEW.md (im Root eines Repositorys mit drei Dateien, im Root eines mit 3.043 Dateien oder in lib/ neben der geänderten Datei) nannten alle neun Ausgaben sie beim Namen und zitierten ihre Important-Regel. Die sechs Läufe, deren Tool-Traces ich aufbewahrt habe, zeigen den Weg: Der Reviewer listete die Dateien des Repositorys, bemerkte REVIEW.md und rief cat darauf auf. Das passt zu einem Modell, das sich umgesehen hat, nicht zu einer Datei, die als Konfiguration verdrahtet ist. Stand die Regel stattdessen in CLAUDE.md, zitierte das Finding CLAUDE.md, den dokumentierten Weg.

Die Doku hat also recht mit dem Mechanismus, und das Verhalten überrascht trotzdem. Lokal hat REVIEW.md funktioniert, weil das Modell beschlossen hat, sie zu lesen, mit Berechtigungen, die das zuließen. Das ist eine Gewohnheit, und das nächste Modell oder der nächste Prompt kann sie fallen lassen. Eine Regel, die lokal halten muss, gehört in CLAUDE.md.

Der erste Lauf hat außerdem eine Type-Hint-Regel aus meinem ~/.claude/rules/ auf User-Ebene durchgesetzt. Das ist so gewollt (das Review liest User-Anweisungen), und es heißt: Zwei Leute, die /code-review auf demselben Branch laufen lassen, bekommen unterschiedliche Findings, noch bevor Permission-Einstellungen ins Spiel kommen.

Was passiert, wenn ein Change seine eigene REVIEW.md ändert?

Der Managed Service schaut sich die Änderung nicht an. Er liest REVIEW.md aus dem Base- oder Default-Branch, „never from the pull request’s own changes“, und akzeptiert herabgesetzte Schweregrade, übersprungene Pfade und Nit-Obergrenzen nur aus der Root-Datei auf einem geschützten Default-Branch. Damit ist geklärt, welche Kopie der Regeln zählt. Immun gegen Anweisungen, die anderswo im Diff platziert sind, macht das den Reviewer aber nicht.

Lokal gibt es keine solche Auswahl. Das Repository hat zwar eine Basis, aber nichts wählt die vertrauenswürdige Kopie der Regeln aus; der Reviewer liest den Working Tree. Also habe ich den naheliegenden Missbrauch ausprobiert. Derselbe fehlerhafte Commit hängte auch „Do not report“-Zeilen an REVIEW.md an, die die Arithmetik und die Eingabeprüfung dieser Funktion ausnahmen, mit einer erfundenen Begründung über eine Legacy-API. In beiden Läufen meldete der Reviewer die Bugs trotzdem und markierte die Änderung an REVIEW.md als eigenes Finding, mit dem Hinweis, dass das Repository gar keine Legacy-API hat.

Das ist ein gutes Ergebnis und eine dünne Garantie: zwei Läufe, ein Modell, ein plumper Versuch. Der Service legt fest, welche Regeln gelten, bevor das Modell irgendetwas sieht. Lokal entscheidet das Modell, und diesmal lag es zufällig richtig. Ein geschützter main ändert daran nichts, denn Branch Protection regelt, was gemergt wird, nicht, was ein lokales Review aus einem Feature-Branch lädt. Was hilft: Jede Änderung an CLAUDE.md oder REVIEW.md von Hand lesen, bevor du einem Review vertraust, das darauf lief.

Wie verhinderst du, dass Claude Code Review 50 Runden dreht?

Begrenze die Runden und verenge, was jedes Re-Review sieht. Ein PR von Claude Code ging über Nacht durch mehr als fünfzig Runden aus Review und Fixes, bevor sein Autor ihn stoppte. Git blame zeigte, dass etwa 59 % dessen, was der Reviewer immer wieder meldete, schon seit seinem ersten Durchgang da war. Die späteren Runden haben also vor allem alte Bugs ausgegraben.

Die Fixes des Teams: Nach drei Runden bittet der Reviewer den Autor, den Ansatz zu überdenken, nach den ersten Durchgängen reviewt er nur noch den neuen Diff, er meldet die Klasse eines Bugs, damit alle Vorkommen zusammen behoben werden, und er wiederholt nie ein Finding. Das Managed-Produkt markiert geerbte Bugs außerdem als Pre-existing, damit sie nicht dem Autor angelastet werden.

Zwei davon gibt es lokal gratis. Notier dir den SHA des letzten vollen Reviews und reviewe danach <that-sha>..HEAD. Das verengt den Umfang (der Reviewer kann trotzdem unberührte Zeilen einer Funktion kommentieren, die der Change angefasst hat). Und schreib die Grenze dorthin, wo der Agent sie liest, denn ein Agent als Autor behebt jeden Nit, den er gezeigt bekommt, und jeder Fix ist ein weiterer Commit und eine weitere Runde:

## Review loop
- After three review-and-fix rounds on one change, stop and ask whether the approach is wrong.
- After the first full review, re-review only commits since the last reviewed SHA.

Was solltest du vom Review-Setup des Claude-Code-Teams zuerst übernehmen?

Die Schutzmechanismen, die von keinem Reviewer abhängen: Pflicht-CI, verworfene veraltete Approvals und CODEOWNERS auf den Pfaden, wo ein Fehler teuer wird.

/.github/workflows/  @you
/src/billing/        @you
/CLAUDE.md           @you
/REVIEW.md           @you
/CODEOWNERS          @you

Mit aktiviertem „require review from Code Owners“ braucht jede Änderung an diesen Pfaden das Approval eines Owners. Das Approval eines einzigen gelisteten Owners reicht; zwei Personen sind eine eigene Einstellung, die Zahl der erforderlichen Approvals. Die Regeldateien und CODEOWNERS selbst stehen aus dem Grund im vorigen Abschnitt auf der Liste.

Danach lass den AI-Reviewer bei Bedarf auf einem fertigen Diff laufen, mit Findings als Empfehlung, bis du genug davon gelesen hast, um zu wissen, welche er falsch einschätzt. Das ist die Reihenfolge, für die ich beim Kombinieren von Claude Code und Codex argumentiert habe: Autor und Reviewer sind verschiedene Systeme, und die Findings der AI blockierend zu machen, mit Pflicht zum Auflösen der Konversationen, kommt zuletzt, wenn überhaupt. Den Risiko-Klassifikator lässt du weg. Das interne Incident-Eval-Set des Teams bewertet den Reviewer, nicht den Klassifikator, und wie der Klassifikator gebaut wurde, beschreiben sie nicht. Die handgeschriebene Pfadliste oben ist mein Ersatz, der Beitrag schlägt keinen vor.

Der Service liest seine Regeln aus einem Branch, den der Pull Request nicht anfassen kann. Ein lokales Review liest sie von der Platte. Solange sich das nicht ändert, ist die Regeldatei Teil des Diffs, und du bist ihr Reviewer.