Code-Review mit Claude: der Ablauf des Claude-Code-Teams

Claude schreibt etwa 90 Prozent des Codes für Claude Code, und das Team liest ihn trotzdem nicht Zeile für Zeile. Stattdessen liegen mehrere Prüfschichten übereinander, und ein Mensch schaut dort hin, wo ein Fehler teuer wäre. Zwischen Juni und September hat sich damit die Zahl der gemergten Pull Requests mehr als verdoppelt, während der Anteil der zurückgenommenen um mehr als 40 Prozent gesunken ist.

Hier ist der Ablauf Schicht für Schicht, mit drei Dateien zum Kopieren und einem Plan, wie du in deinem eigenen Projekt anfängst.

Was du brauchst

Du brauchst Claude Code, im Terminal oder in der Desktop-App im Reiter Code, und ein Git-Projekt mit Pull Requests, etwa auf GitHub. Die automatische Review auf jedem Pull Request gibt es als Produkt „Code Review for Claude Code“ für Team- und Enterprise-Kunden. Ohne das arbeitest du mit den lokalen Befehlen /code-review und /security-review.

Die Idee dahinter

„Hat jemand den Code gelesen?“ sagt wenig. Das Team fragt stattdessen: Was kann bei dieser Änderung schiefgehen, und welcher Check, automatisch oder von Hand, fängt es? Die Prüfung läuft deshalb mit, wie eine Rechtschreibprüfung beim Schreiben, und nicht erst am Ende. Die meisten Änderungen hat Claude mindestens einmal geprüft und korrigiert, bevor ein Mensch hinsieht.

Jede Schicht fängt einen Teil der Fehler und lässt andere durch. Wenige kommen durch alle, und für die gibt es den Rollback.

Vor dem Pull Request: Claude zeigt das Ergebnis

Bevor ein Pull Request entsteht, lässt das Team Claude etwas Ausführbares tun: Tests laufen lassen, den Build starten oder einen Screenshot mit dem Design vergleichen. Statt „fertig“ zu melden, zeigt Claude das Ergebnis. Danach prüft ein Subagent mit frischem Kontext den Diff. Viele im Team lassen davor eigene Skills laufen, etwa für Bug-Suche, kleinere Diffs, Ende-zu-Ende-Tests und den Abgleich der Oberfläche mit den Design-Richtlinien.

Für dein Projekt schreibst du die Checkliste in eine kurze CLAUDE.md. Die Datei gibt Claude den Projektkontext und wird bei jedem Durchgang gelesen, deshalb bleibt sie kurz.

## Vor dem Pull Request
- Führe Tests und Build aus und zeig mir die Ausgabe. Melde nie „fertig“ ohne Ergebnis.
- Bei UI-Änderungen: Screenshot machen und mit dem Design vergleichen.
- Lass einen Subagent den Diff mit frischem Kontext prüfen.
- Fülle im Pull Request „Testing“, „Risk“ und „How to revert“ aus.

Formatter und Linter lässt du per Hooks laufen, dann ruft Claude sie nach Änderungen selbst auf. Vor dem Pull Request startest du lokal /code-review und /security-review.

AI-Review auf jedem Pull Request

Jeder Pull Request bekommt ein Claude-Review, bevor ein Mensch ihn sieht. Das Review prüft den Diff gegen die ganze Codebase und gegen das, was der Autor mit dem Pull Request erreichen will: Löst die Änderung das Problem, passt sie ins System, bricht sie nichts? Bei Bugfixes sucht es die Ursache.

Mehrere Agenten suchen parallel nach Bugs, eine Abstimmung trennt echte Funde von Fehlalarmen, und reine Stil-Funde fliegen raus. Was übrig bleibt, kommt als Kommentar nach Schwere: Important, Nit oder Pre-existing, damit der Autor nicht für alte Fehler haftet. Alle Funde müssen gelöst werden, entweder durch einen Fix oder durch das Schließen des Threads mit einer Begründung. Oft behebt ein Agent das über Nacht.

Die Datei REVIEW.md sagt dem Reviewer, was in deinem Code zählt. Gut ist sie kurz und legt fest, was in diesem Projekt als Fehler gilt, dass nicht mit Kleinkram genervt wird, welche Pfade ignoriert werden, dass jeder Fund Datei und Zeile nennt und dass oben eine Zusammenfassung mit der Anzahl der Funde steht oder der klare Satz, dass nichts gefunden wurde.

# REVIEW.md

## Was in diesem Projekt als Fehler zählt
- Die Doku darf nicht lügen.
- Die Config darf nichts falsch routen.
- [Ergänze deine eigenen Punkte.]

## Nicht beanstanden
- Stilfragen und Kleinigkeiten, die kein Fehler sind.

## Ignorierte Pfade
- [Pfade eintragen, zum Beispiel generierter Code]

## Format der Funde
- Jeder Fund nennt Datei und Zeile. Keine geratenen Dateinamen.
- Oben steht eine Zusammenfassung mit der Anzahl der Funde,
  oder der klare Satz „Keine Probleme gefunden“.

Starte auf einem einzigen Repo und schärfe die REVIEW.md ein paar Wochen nach, bevor du das Review auf weitere Repos ausrollst. Verlange, dass alle Review-Threads vor dem Merge gelöst sind. Die Strenge richtet sich nach dem Risiko: Im Produkt gibt es die Stufen Quick, Standard und Deep, und Deep lohnt sich, wenn ein übersehener Bug teurer ist als die Review-Zeit.

Security-Review, der blockt

Auf jedem Pull Request läuft zusätzlich eine automatische Sicherheitsprüfung. Solange ein Fund offen ist, aus dem Code-Review oder aus dem Security-Review, geht der Merge nicht durch. Der Autor behebt den Fund oder schließt den Thread mit einer kurzen Begründung, wenn es ein Fehlalarm war. Behebt ein späterer Commit das Problem, schließt sich der Fund von selbst.

Lokal startest du den Security-Review mit /security-review. Für Pull Requests auf GitHub gibt es die Open-Source-GitHub-Action für Security-Reviews.

Automatische Checks und Template

Lint, Typprüfung, Tests auf allen Plattformen und der Build laufen auf jedem Pull Request und blockieren den Merge. Ein typischer Pull Request im Claude-Code-Team durchläuft Dutzende Checks, bevor ein Mensch hinsieht.

Das Pull-Request-Template stellt drei Fragen: wie die Änderung getestet wurde, wie groß das Risiko ist und wie man sie zurückrollt. Claude kann sie beantworten, der Autor bleibt dafür verantwortlich. Leg die Datei als .github/pull_request_template.md an.

## Testing
Wie wurde die Änderung getestet? (Befehle und Ergebnis)

## Risk
Was kann schiefgehen, und wie groß wäre der Schaden?

## How to revert
Wie rolle ich die Änderung in einem Schritt zurück?

Menschliche Freigabe nach Risiko

Ein Doku-Fix ist nicht dasselbe wie eine Änderung am Auto-Updater, und deshalb braucht nicht jede Änderung gleich viel Mensch. Das Risiko bestimmt ein Klassifizierer anhand der Änderung und nicht anhand des Autors. Ein zweiter Klassifizierer entscheidet, ob trotz niedriger Stufe eine weitere Freigabe nötig ist.

Diese Regeln gelten dabei:

• Pfade, die ihre Owner als sensibel markiert haben, und jede CI-Workflow-Datei brauchen immer eine weitere Freigabe.
• Lockerere Regeln bekommen nur Autoren auf einer Trusted-Liste, meist das Team, dem das Repo gehört. Alle anderen brauchen eine zweite Person.
• Freigaben von Agenten zählen nicht als menschliche. Wer einen Agenten betreibt, zählt als einer der Pflicht-Reviewer.
• Eine Freigabe gilt nur für einen Commit. Kommt danach etwas dazu, dem niemand trauen kann, etwa ein Commit von einem Agenten oder eine von Hand aufgelöste Merge-Konflikt-Stelle, muss neu freigegeben werden.

Bei dir setzt du das mit CODEOWNERS und Branch Protection um. Menschen prüfen immer Code für Login, Abrechnung, CI, Release-Workflows und Installer. Dazu kommen zwei Fragen, die keine Maschine entscheidet: Soll das überhaupt gebaut werden, und ist die Architektur richtig, weil sie die Konventionen für alles Weitere setzt.

Merge Queue, Feature Flags, Rollback

Die Merge Queue lässt alle Checks auf main mit der Änderung laufen, so werden nicht zwei einzeln grüne Pull Requests zu einem kaputten main. Neue Features laufen hinter einem Feature Flag und gehen erst an interne Nutzer. Öffentlich geht es zuerst in den Latest-Channel, und Stable zieht später nach.

Einzelne schlechte Merges kommen trotzdem durch, und dafür gibt es die letzte Verteidigungslinie. Was hinter einem Feature Flag liegt, schaltest du ab, ohne neu auszuliefern. Jedes Incident-Review fragt danach, welche Schicht den Fehler hätte fangen müssen, und die Antwort wandert in einen neuen Check, einen Skill oder die CLAUDE.md.

Damit der Reviewer besser wird, sammelt das Team die Pull Requests, die Incidents verursacht haben, samt Fix-Forwards und Reverts. Das Review-System wird täglich gegen diese Sammlung bewertet, und jede Änderung an Prompts, Tools oder Modell läuft erst dagegen. Gemessen wird außerdem, wie die Autoren auf Kommentare reagieren: behoben, abgelehnt, als gewollt erklärt oder egal.

So läuft das Review nicht im Kreis

Autor-Agent und Review-Agent können sich endlos hin- und herschicken. Im Claude-Code-Team lief ein Pull Request über Nacht mehr als fünfzig Runden im Kreis, bis jemand von Hand stoppte. Etwa 59 Prozent dessen, was das Review markierte, war Code, der schon im ersten Durchlauf da war: Es fand kaum neue Bugs, sondern pro Runde ein paar alte. Seitdem gelten vier Regeln, die du in deine REVIEW.md schreibst.

## Review-Runden
- Nach drei Runden prüft der Autor, ob der Ansatz stimmt.
- Spätere Runden prüfen nur den neuen Diff.
- Nenne die Bug-Klasse, damit alle Fälle auf einmal behoben werden.
- Melde nichts erneut, was schon gemeldet wurde.

So steigst du ein

Fang vorne am Weg einer Änderung an und arbeite dich nach hinten.

1. Vor dem Pull Request: Block in die CLAUDE.md, Formatter und Linter per Hooks, /code-review und /security-review lokal, REVIEW.md anlegen.
2. Auf jedem Pull Request: CI erzwingen, das Template einsetzen, einen AI-Reviewer auf einem Repo testen und die REVIEW.md ein paar Wochen nachschärfen, den Security-Review einschalten, offene Review-Threads blockieren lassen, die Review-Runden begrenzen.
3. Freigabe: Risikostufen nach der Änderung festlegen, mit strengen Regeln starten und erst mit Belegen lockern. CODEOWNERS und Branch Protection für Login, Abrechnung, CI, Release und Installer. Bot-Freigaben zählen nicht.
4. Merge und danach: Merge Queue, Feature Flags, interne Nutzer zuerst, Rollout in Stufen, ein Schritt zum Zurückrollen. Aus jedem Incident und jedem Revert entsteht ein Test für den Reviewer.

Starte streng und lockere die Regeln erst, wenn du Belege dafür siehst.