Claude Code Review automatische PR-Prüfung im Team.
Claude Code Review ist der von Anthropic betriebene Prüfdienst, der Pull Requests auf GitHub automatisch durchsieht und Funde als Inline-Kommentare mit Schweregrad an die betroffenen Zeilen hängt. Stand Oktober 2026 ist er eine Research Preview für die Pläne Team und Enterprise und kostet laut Anthropic im Schnitt 15 bis 25 US-Dollar pro Review, abgerechnet über Usage Credits. Ob sich das lohnt, entscheiden drei Stellschrauben: wann ein Review ausgelöst wird, was in der Datei REVIEW.md steht und wie Sie die Ergebnisse in Ihre CI einbinden. Dieser Leitfaden zeigt den Ablauf, rechnet die Kosten durch, gibt ein Beispiel für domänenspezifische Pflichtprüfungen in einem Trading-Repository und grenzt den Cloud-Dienst vom lokalen Befehl /code-review ab, den es für alle Pläne gibt. Eines vorweg: Ein KI-Review ersetzt keine Tests.
Was ist Claude Code Review und für wen ist es verfügbar?
Claude Code Review ist ein verwalteter Dienst von Anthropic, der über die Claude-GitHub-App an Ihre Repositories angebunden wird. Läuft ein Review, untersuchen mehrere spezialisierte Agenten parallel den Diff (die Änderungen des PRs) und den umgebenden Code auf Anthropic-Infrastruktur. Jeder Agent sucht eine andere Fehlerklasse: Logikfehler, Sicherheitslücken, kaputte Randfälle, schleichende Regressionen. Ein Verifikationsschritt prüft die Kandidaten anschließend gegen das tatsächliche Codeverhalten, um Fehlalarme auszusortieren. Was übrig bleibt, wird dedupliziert, nach Schwere sortiert und als Inline-Kommentar gepostet, dazu eine Zusammenfassung. Laut Dokumentation dauert ein Review im Schnitt rund 20 Minuten.
Jeder Fund trägt einen von drei Schweregraden:
| Schweregrad | Bedeutung | Sinnvolle Reaktion |
|---|---|---|
| Important (rot) | Fehler, der vor dem Merge behoben werden sollte | beheben oder begründet verwerfen |
| Nit (gelb) | Kleinigkeit, sinnvoll, aber nicht blockierend | nach Ermessen |
| Pre-existing (lila) | Fehler, der schon vorher im Code war und nicht aus diesem PR stammt | als Ticket erfassen |
Zur Verfügbarkeit, Stand Oktober 2026: Der Dienst ist eine Research Preview, also eine Vorabversion, deren Umfang sich noch ändern kann, und nur in den Plänen Team und Enterprise enthalten. Organisationen mit Zero Data Retention (Anthropic speichert Ein- und Ausgaben nicht) oder mit HIPAA-Konfiguration sind ausgeschlossen. Einrichten muss ihn ein Owner der Claude-Organisation in den Claude-Code-Admin-Einstellungen; er braucht zusätzlich das Recht, GitHub-Apps in der GitHub-Organisation zu installieren. Danach wählt er die Repositories aus und legt je Repository fest, wann Reviews laufen. Standardmäßig konzentriert sich der Dienst auf Korrektheit, also auf Fehler, die in Produktion etwas kaputt machen, nicht auf Formatierung oder fehlende Testabdeckung. Für GitLab und selbst gehostete GitHub-Instanzen dokumentiert Anthropic eigene Wege über GitLab CI/CD beziehungsweise GitHub Enterprise Server.
Was kostet ein Review und wie begrenzen Sie die Ausgaben?
Abgerechnet wird nach Tokenverbrauch. Anthropic nennt einen Durchschnitt von 15 bis 25 US-Dollar pro Review; der Betrag steigt mit der Größe des PRs, der Komplexität der Codebasis und der Zahl der Funde, die verifiziert werden müssen. Die Kosten laufen über Usage Credits, also nutzungsabhängig berechnetes Zusatzguthaben, und zählen nicht auf das im Plan enthaltene Kontingent. Sie erscheinen auf der Anthropic-Rechnung, auch wenn Ihr Team Claude Code sonst über Amazon Bedrock oder Google Cloud nutzt.
Der größte Hebel ist der Trigger, den Sie je Repository wählen:
- Einmal nach PR-Erstellung: ein Review, wenn der PR geöffnet oder als bereit markiert wird. Gut planbar, spätere Commits prüft der Dienst aber nicht von selbst.
- Nach jedem Push: neue Probleme werden laufend erkannt, behobene Threads automatisch geschlossen. Die Kosten multiplizieren sich mit der Zahl der Pushes.
- Manuell: Reviews nur auf Kommentar,
@claude reviewfür einen einzelnen Lauf,@claude review alwaysfür alle folgenden Pushes dieses PRs. Sinnvoll für Repositories mit viel Verkehr.
Rechenbeispiel: Ein Team mit 40 PRs im Monat landet im Modus „einmal“ bei 15 bis 25 US-Dollar pro Review bei rund 600 bis 1.000 US-Dollar. Mit „nach jedem Push“ und im Schnitt vier Pushes pro PR wären es grob 2.400 bis 4.000 US-Dollar, sofern die Folge-Reviews ähnlich teuer sind. Das sind Annahmen auf Basis der Herstellerangabe, keine Messwerte. Die tatsächlichen Zahlen zeigen die Spalte mit den Durchschnittskosten je Repository in den Admin-Einstellungen und das Analytics-Dashboard mit den wöchentlichen Kosten; verbindlich ist die Anthropic-Rechnung.
Ein monatliches Ausgabenlimit setzen Sie in den Nutzungseinstellungen der Organisation für den Dienst „Claude Code Review“. Ist es erreicht oder sind die Credits aufgebraucht, überspringt der Dienst Reviews und hinterlässt einen Hinweis im PR. Pull Requests aus Forks prüft er in keinem Modus automatisch, sondern nur auf Kommentar; dort entstehen also keine Kosten pro Push.
REVIEW.md: Schweregrade, Nit-Grenze und Pflichtprüfungen festlegen.
Code Review liest zwei Dateien aus dem Repository. Die CLAUDE.md enthält allgemeine Projektanweisungen für alle Claude-Code-Aufgaben; neu eingeführte Verstöße dagegen meldet der Review als Nit. Das gilt auch umgekehrt: Macht ein PR eine Aussage in der CLAUDE.md überholt, weist der Review darauf hin. Die REVIEW.md im Wurzelverzeichnis gilt dagegen nur für den Review. Ihr Inhalt geht direkt an die Agenten, die Funde suchen und verifizieren, und auch die Agenten, die Schweregrade festlegen, ziehen sie heran. Regeln dort greifen deshalb zuverlässiger als dieselben Regeln in einer langen CLAUDE.md.
Am meisten bewirken in der REVIEW.md:
- Schweregrad: eine eigene Definition, was Important in diesem Repository bedeutet. Sie können auch hochstufen, etwa jeden CLAUDE.md-Verstoß als Important behandeln.
- Nit-Grenze: eine Obergrenze pro Review, der Rest nur als Anzahl in der Zusammenfassung.
- Skip-Regeln: generierter Code, Lockfiles, eingebundene Fremdbibliotheken und alles, was Linter ohnehin prüfen.
- Pflichtprüfungen: Regeln, die bei jedem PR geprüft werden sollen.
- Belegpflicht: Aussagen über Verhalten nur mit
file:line-Angabe, nicht aus Namen geschlossen. - Folge-Reviews: etwa „nach dem ersten Review nur noch Important“, damit ein Einzeiler nicht in die siebte Stilrunde geht.
Typisches Beispiel für ein Python-Repository mit Trading-Logik. Dort gehören Look-ahead-Fehler (die Strategie greift auf Daten zu, die zum Entscheidungszeitpunkt noch nicht existierten) und lückenhafte Orderprüfungen zu den teuersten Fehlerklassen, weil sie Backtests schönen oder im Live-Betrieb echte Orders auslösen. Genau diese Klassen gehören in die Pflichtprüfungen:
# Review-Anweisungen ## Was hier „Important“ heißt Important nur für Fehler, die Orders, Positionsgrößen oder Backtest-Ergebnisse verfälschen: falsche Orderlogik, Look-ahead, fehlende Größen- oder Verlustlimits, Zeitzonenfehler an Session-Grenzen. Stil und Benennung sind höchstens Nit. ## Nits begrenzen Höchstens fünf Nits pro Review, den Rest nur als Anzahl in der Zusammenfassung. ## Nicht melden - Was die CI schon prüft: ruff, mypy, Formatierung - Generierte Dateien unter data/cache/ und jede *.lock-Datei - In notebooks/ nur nahezu sichere, schwere Fehler ## Immer prüfen - Signale nutzen nur abgeschlossene Bars, nie die laufende Kerze - Jede neue Orderfunktion prüft maximale Positionsgröße und Tagesverlustlimit - Änderungen an der Orderlogik haben einen Test in tests/execution/ - Aussagen über Verhalten brauchen eine file:line-Angabe ## Folge-Reviews Nach dem ersten Review nur noch Important-Funde melden.
Halten Sie die Datei kurz. Die Dokumentation warnt ausdrücklich, dass eine lange REVIEW.md die wichtigen Regeln verwässert; allgemeiner Projektkontext bleibt in der CLAUDE.md. Laut Changelog vom 06.10.2026 (Version 2.1.292) nutzt der Review bei PRs, die die CLAUDE.md selbst ändern, deren Fassung aus dem Basis-Branch. Ein PR kann die CLAUDE.md-Regeln für seinen eigenen Review also nicht lockern.
Warum der Check nie blockiert: CI-Gating mit gh und jq.
Jedes Review befüllt einen Check-Run namens „Claude Code Review“ neben Ihren übrigen CI-Checks. Er endet immer mit dem Ergebnis „neutral“. Über Branch-Protection-Regeln kann er deshalb keinen Merge verhindern, auch nicht nach einem fehlgeschlagenen oder abgebrochenen Lauf. Das ist gewollt: Der Dienst ergänzt bestehende Review-Prozesse, statt sie zu ersetzen, und Läufe sind laut Anthropic Best-Effort. Ein Dienst, der gelegentlich ausfällt, soll keine Releases aufhalten.
Wer Merges trotzdem von den Funden abhängig machen will (CI-Gating), liest die Zählung selbst aus. Die letzte Zeile im Detailtext des Check-Runs ist ein maschinenlesbarer Kommentar mit den Fundzahlen je Schweregrad, etwa {"normal": 2, "nit": 1, "pre_existing": 0}. Der Schlüssel normal steht für Important-Funde. Ein Prüfschritt in der eigenen CI kann so aussehen:
# OWNER/REPO anpassen, SHA = Kopf-Commit des Pull Requests
ID=$(gh api repos/OWNER/REPO/commits/$SHA/check-runs \
--jq '.check_runs[] | select(.name == "Claude Code Review") | .id')
COUNTS=$(gh api repos/OWNER/REPO/check-runs/$ID \
--jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson')
IMPORTANT=$(echo "$COUNTS" | jq '.normal')
if [ "$IMPORTANT" -gt 0 ]; then
echo "Claude Code Review: $IMPORTANT Important-Fund(e)"
exit 1
fiZwei Punkte gehören zur Gestaltung. Erstens läuft ein Review asynchron und braucht Zeit; Ihr Gate muss warten, bis der Claude-Check abgeschlossen ist, sonst findet es keine Zählung. Zweitens müssen Sie festlegen, was ohne Review passiert. Ein Gate, das bei fehlender Zählung hart abbricht, macht einen Best-Effort-Dienst zur Pflichtbedingung. Ein Gate, das dann durchlässt, öffnet eine Lücke. Eine pragmatische Mischform: Important-Funde blockieren, ein fehlender Review erzeugt nur eine Warnung, und ein Mensch kann per Label bewusst freigeben, wenn ein Fund nachweislich falsch ist.
Lokal statt Cloud: /code-review mit --fix und --max-findings.
Der Cloud-Dienst ist nicht die einzige Variante. In jeder Claude-Code-Sitzung steht der Befehl /code-review (Alias /review) zur Verfügung, auch auf Plänen ohne Code Review. Er prüft die Commits Ihres Branches gegenüber dem Upstream plus nicht committete Änderungen, alternativ eine Datei, eine PR-Nummer, einen Branch oder einen Bereich wie main...feature. Er läuft als Hintergrund-Subagent mit eigenem Kontext und zählt auf das normale Nutzungskontingent.
--fixwendet die Funde direkt im Arbeitsverzeichnis an. Läuft der Review im Hintergrund, macht/rewinddiese Änderungen nicht rückgängig; zurücknehmen geht dann über Git.--commentpostet die Funde als Inline-Kommentare in einen GitHub-PR oder als Notiz in einen GitLab-Merge-Request (über die CLIglab).--max-findings <n>oderallmeldet mehr oder weniger Funde als die übliche Grenze, verfügbar seit Version 2.1.288 vom 02.10.2026. Der Wert bleibt gespeichert, bis Sie--max-findings defaultangeben.- Effort-Stufe: Bei
lowundmediummeldet der Review nur Funde, bei denen er sich sicher ist;highbismaxdecken mehr ab, mit mehr Unsicherheit.
Wichtig für die Abstimmung im Team: Der lokale Review folgt der CLAUDE.md, liest aber die REVIEW.md nicht. Regeln, die lokal und in der Cloud gelten sollen, gehören deshalb in die CLAUDE.md. Im Cloud-Review erscheinen Verstöße dagegen nur als Nit, es sei denn, die REVIEW.md stuft sie hoch. Für eine tiefere Prüfung vor dem Merge startet /code-review ultra einen Multi-Agenten-Review in der Cloud. Auf Pro und Max sind drei Läufe einmalig frei, danach kostet ein Lauf laut Anthropic typischerweise 5 bis 25 US-Dollar in Usage Credits. Über Amazon Bedrock, Google Cloud oder Microsoft Foundry sowie mit Zero Data Retention steht diese Cloud-Prüfung nicht zur Verfügung. Für Skripte und CI gibt es dafür den Unterbefehl claude ultrareview, der auf das Ergebnis wartet.
Grenzen: Datenhaltung, Fehlalarme, Review ersetzt keine Tests.
- Datenhaltung: Der Review läuft auf Anthropic-Infrastruktur, der Code verlässt also Ihre Umgebung. Für Organisationen mit Zero Data Retention gibt es den Dienst nicht. Klären Sie mit Datenschutz und Informationssicherheit, welche Repositories in Frage kommen. Repositories mit Kundendaten, Zugangsdaten oder besonders schützenswertem Know-how nehmen Sie im Zweifel zunächst aus.
- Breite App-Rechte: Die Claude-GitHub-App bringt einen gemeinsamen Rechtesatz für alle Claude-Funktionen mit, darunter Schreibrechte auf Inhalte, Workflows und Actions. Eine Teilmenge lässt GitHub nicht zu. Geben Sie der App nur Zugriff auf die Repositories, die tatsächlich geprüft werden sollen.
- Fehlalarme und Lücken: Der Verifikationsschritt filtert, aber nicht perfekt. Funde sind begründete Hinweise, kein Urteil; „keine Funde“ heißt nicht „fehlerfrei“. Daumen-hoch- und Daumen-runter-Reaktionen an den Kommentaren wertet Anthropic nach dem Merge aus, um den Reviewer abzustimmen.
- Review ersetzt keine Tests: Standardmäßig prüft der Dienst Korrektheit, nicht Testabdeckung. Einen Look-ahead-Fehler kann ein KI-Review übersehen, ein gezielter Test mit Zeitstempelprüfung findet ihn reproduzierbar. Tests, Typprüfung und ein menschlicher Reviewer bleiben; der KI-Review ist eine zusätzliche Schicht.
- Research Preview: Funktionen, Preise und Verfügbarkeit können sich ändern. Ein fehlgeschlagener Lauf blockiert nichts, prüft aber auch nichts.
- Stolperstein bei Kommentar-Triggern: Ist Ihre Mitgliedschaft in der GitHub-Organisation privat (GitHub-Standard), startet
@claude reviewunter Umständen keinen Review, obwohl Sie über Team-Rechte schreiben dürfen. Abhilfe: Mitgliedschaft öffentlich machen oder direkt als Collaborator eintragen lassen.
Pilot in einem Repository: so gehen Sie vor.
- Repository wählen: eines mit regelmäßigen PRs, ordentlicher Testabdeckung und ohne besonders sensible Daten. So sehen Sie, was der Review zusätzlich zu den Tests findet.
- Budget festlegen: das monatliche Ausgabenlimit für Claude Code Review setzen, bevor der erste PR läuft. Für den Pilot reicht der Modus „einmal nach PR-Erstellung“ oder „manuell“.
- REVIEW.md schreiben: kurz, mit eigener Important-Definition, Nit-Grenze, Skip-Regeln und drei bis fünf Pflichtprüfungen aus Ihrer Domäne.
- Zwei bis vier Wochen auswerten: Wie viele Important-Funde waren echt? Wie viele hätten Tests oder der menschliche Review ohnehin gefunden? Was kostete ein Review im Schnitt laut Admin-Übersicht? Reaktionen an den Kommentaren konsequent setzen.
- Erst dann ein Gate einbauen: Wenn die Trefferquote stimmt, das CI-Gate auf Important-Funde mit bewusster Freigabemöglichkeit ergänzen.
- Lokal vorprüfen: Entwickler lassen vor dem Push
/code-reviewlaufen. Das fängt Kleinkram ab, bevor ein Cloud-Review dafür bezahlt wird.
Wie sich das in eine breitere Einführung mit Rechten, Sandbox und Kosten einfügt, beschreibt der Artikel Claude Code im Unternehmen einführen. Für saubere Branch- und PR-Abläufe in kleinen Teams hilft der Beitrag zu Git-Workflows für Trader-Teams. Wenn Sie den Pilot strukturiert aufsetzen oder Ihr Team in Claude Code schulen möchten, unterstütze ich Sie in der KI-Beratung.
Häufige Fragen.
Was kostet Claude Code Review pro Pull Request?
Laut Anthropic kostet ein Review im Schnitt 15 bis 25 US-Dollar, Stand Oktober 2026. Abgerechnet wird nach Tokenverbrauch über Usage Credits, nicht über das Plankontingent. Große PRs und komplexe Codebasen kosten mehr. Entscheidend ist der Trigger: Reviews nach jedem Push vervielfachen die Kosten, einmalige oder manuelle Reviews halten sie planbar. Ein monatliches Ausgabenlimit lässt sich in den Admin-Einstellungen setzen.
Kann Claude Code Review einen Merge blockieren?
Nein, nicht direkt. Der Check-Run „Claude Code Review“ endet immer mit dem Ergebnis neutral und greift deshalb nicht in Branch-Protection-Regeln ein. Wer Merges von den Funden abhängig machen will, liest die Schweregrad-Zählung aus dem Check-Run mit gh und jq in der eigenen CI aus und lässt den eigenen Prüfschritt bei Important-Funden fehlschlagen.
Was ist der Unterschied zwischen REVIEW.md und CLAUDE.md?
Die CLAUDE.md enthält allgemeine Projektregeln für alle Claude-Code-Aufgaben; Verstöße meldet Code Review als Nit. Die REVIEW.md im Wurzelverzeichnis gilt nur für den Review und legt fest, was Important bedeutet, wie viele Nits erscheinen, was übersprungen wird und was immer geprüft werden muss. Der lokale Befehl /code-review liest nur die CLAUDE.md.
Gibt es Claude Code Review auch für Pro- oder Max-Nutzer?
Der automatische PR-Review auf GitHub ist Stand Oktober 2026 nur in Team und Enterprise enthalten. Auf allen Plänen steht aber der lokale Befehl /code-review zur Verfügung, der einen Diff im Terminal prüft und Funde mit --fix anwenden oder mit --comment posten kann. Für eine tiefere Cloud-Prüfung gibt es /code-review ultra mit drei einmaligen Freiläufen auf Pro und Max.
Ersetzt ein KI-Code-Review den menschlichen Review oder Tests?
Nein. Claude Code Review prüft standardmäßig auf Korrektheitsfehler und filtert Fehlalarme, findet aber nicht alles und erzeugt gelegentlich falsche Funde. Tests liefern reproduzierbare Belege, menschliche Reviewer bewerten Architektur und fachliche Absicht. Sinnvoll ist der KI-Review als zusätzliche Schicht, die offensichtliche und versteckte Fehler früher sichtbar macht.
Quellen und Stand.
- Code Review — Anthropic (Claude Code Docs)
- Find bugs with ultrareview — Anthropic (Claude Code Docs)
- Claude Code Changelog — Anthropic (Claude Code Docs)
- Claude Code GitHub Actions — Anthropic (Claude Code Docs)
- Manage usage credits for Team and seat-based Enterprise plans — Anthropic Help Center
Stand: 7. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.
Sie wollen KI-Code-Review in Ihrem Entwicklungsteam mit klaren Regeln einführen? Unverbindlich anfragen — wir klären Pilot-Repository, Regeln in der REVIEW.md, Budget und die Schulung Ihres Teams. Mehr zu meinem Angebot: KI-Workshops für Unternehmen und KI-Beratung.