Claude Code Review: Was es findet und was nicht

Sie haben Ihr erstes Claude Code Review laufen lassen und eine Liste zurückbekommen. Ein Fund war scharf genug, um den Merge zu stoppen. Drei waren Rauschen. Jetzt haben Sie keine Ahnung, welcher Hälfte Sie beim nächsten Mal trauen sollen oder wonach der Reviewer überhaupt nie gesucht hat.

Hier ist die ehrliche Form der Sache: was das Review zuverlässig findet, was es halb findet, was es strukturell nicht beurteilen kann, egal wie Sie es prompten, und welche Konfiguration darüber entscheidet, was Sie davon bekommen.

Die wichtigsten Erkenntnisse

• Drei Dinge werden "Claude Code Review" genannt: der lokale Befehl /code-review, die gemanagte GitHub App und ein Review-Skill, den Sie selbst schreiben. Sie lesen unterschiedliche Konfigurationsdateien.
• Am stärksten ist es bei allem, was es durch Lesen des Codes verifizieren kann: unbehandelte Fehlerpfade, veraltete Aufrufer nach einer Signaturänderung, nicht eingegrenzte Queries, Geheimnisse, die in Logs landen, die Reichweite einer Migration.
• Am schwächsten ist es überall dort, wo Urteilsvermögen gefragt ist: ob das Feature überhaupt existieren sollte oder ob die Abstraktion in sechs Monaten wehtut.
• REVIEW.md ist die nützlichste Datei, die Sie hinzufügen können: Sie kalibriert den Schweregrad neu, deckelt die Menge an Kleinigkeiten und listet auf, was zu überspringen ist. Die Doku von Anthropic sagt, dass der gemanagte Reviewer sie liest, der lokale Befehl nicht, und dass die Standardkalibrierung auf Korrektheit zielt, nicht auf Formatierung oder Testabdeckung.
• Das meiste Review-Rauschen ist ein Kontextproblem, kein Modellproblem.

---

Drei verschiedene Dinge, die Menschen mit "Claude Code Review" meinen

Bevor Sie über Qualität streiten, werden Sie konkret, welches davon Sie ausgeführt haben.

Lokal. /code-review prüft die Commits Ihres Branches, die vor dem Upstream liegen, plus nicht committete Änderungen. Übergeben Sie ein Ziel für alles andere: einen Dateipfad, eine PR-Nummer, einen Branch oder einen Bereich wie main...my-feature. Es läuft als Hintergrund-Subagent mit eigenem Kontextfenster und frisst Ihre Sitzung daher nicht auf.

/code-review medium                 # branch vs upstream, plus uncommitted work
/code-review high main...my-feature # broader coverage on a specific range
/code-review --fix                  # apply the findings to your working tree

Der Effort Level ist der Regler, den die meisten übersehen. Die Doku ist eindeutig: low und medium melden nur die Funde, bei denen das Review am sichersten ist, während high bis max die Abdeckung verbreitern und auch Funde enthalten können, bei denen es weniger sicher ist. Wenn Sie in Kleinigkeiten ertrinken, senken Sie den Effort, bevor Sie das Modell beschuldigen. Ein Fallstrick: Ein --fix im Hintergrund landet außerhalb Ihrer Sitzungs-Checkpoints, /rewind macht es also nicht rückgängig. Nutzen Sie Git.

Auf Pull Requests, gemanagt. Ein Organisations-Owner aktiviert Code Review in den Claude-Code-Admin-Einstellungen, installiert die Claude GitHub App, wählt die Repositories im Geltungsbereich und setzt pro Repo ein Review Behavior: einmal nach PR-Erstellung, nach jedem Push oder manuell. Manuell ist die vernünftige Voreinstellung für ein vielbefahrenes Repo, weil Sie PRs per Kommentar hineinnehmen:

@claude review          # one review, no subscription
@claude review always   # review now, and on every later push
@claude review once     # same as the bare command

Die Doku ist streng bei der Form: Kommentar auf oberster PR-Ebene, Befehl am Anfang, von einem Konto mit Owner-, Member- oder Collaborator-Zugriff, an einem offenen PR. Unter der Haube beschreibt Anthropic mehrere Agents, die das Diff parallel analysieren, gefolgt von einem Verifikationsschritt, der Kandidaten gegen das tatsächliche Codeverhalten prüft. Was übrig bleibt, erscheint als Inline-Kommentar mit der Kennzeichnung Important, Nit oder Pre-existing, dazu ein Claude Code Review Check Run, der immer neutral abschließt und daher nie einen Merge blockiert. Zwei Grenzen: Es ist eine Research Preview in den Team- und Enterprise-Tarifen, nicht verfügbar bei aktivierter Zero Data Retention, und die Doku beziffert es auf 15 bis 25 Dollar pro Review. Deshalb ist "Review bei jedem Push" eine Entscheidung und keine Voreinstellung.

In Ihrer eigenen CI. Um Claude stattdessen in Ihrer eigenen Infrastruktur laufen zu lassen, verweist die Doku auf GitHub Actions oder GitLab CI/CD. Dann gehören Ihnen die Auslöselogik, der Prompt und die Filterung.

Was der Reviewer tatsächlich findet

Ein KI-Reviewer ist ausgezeichnet bei Arbeit, die mühsam, mechanisch und durch sorgfältiges Lesen überprüfbar ist, also genau bei dem, was menschliche Prüfer überspringen, wenn sie müde sind.

Fehlerpfade, die niemand getestet hat. Der Happy Path wird geprüft, weil die PR-Beschreibung ihn beschreibt. Der Reviewer liest die Zweige, die Sie nicht gelesen haben: das fehlgeschlagene Parsen, den Aufruf im Timeout, die leere Liste. Anthropics eigenes Beispiel ist eine Funktion, die bei fehlerhafter Eingabe still 0 zurückgibt, sodass der Aufrufer "null" nicht von "kaputt" unterscheiden kann.

Breaking Changes mit veralteten Aufrufern. Sie haben eine Signatur geändert, drei Aufrufstellen aktualisiert und die vierte in einem Verzeichnis verpasst, das Sie nie öffnen. Ein Agent mit Repository-Zugriff findet sie durch Suchen, nicht durch Erinnern.

Mechanische Konsistenz. Jedes andere Modul validiert an der Grenze und dieses eine irgendwo in der Mitte. Jeder andere Handler gibt einen typisierten Fehler zurück und dieser einen String. Kein Mensch findet das über ein Diff mit 40 Dateien hinweg.

Bekannte Sicherheitsmuster. Query-Verkettung, ein Datenbankaufruf, der nicht auf den Mandanten des Aufrufers eingegrenzt ist, ein Request Body, der in einer Log-Zeile landet, ein Token-Vergleich ohne konstante Laufzeit. Musterabgleich ist das, worin das Modell gut ist.

Reichweite einer Änderung. Sie haben eine Abhängigkeit angehoben oder eine Migration ergänzt. Die interessante Frage ist alles, was hinter dem Diff liegt. Ein Agent, der die ganze Codebasis erreicht, verfolgt die Aufrufer und die Tabellen. Ein Prüfer in einem Browser-Tab nicht.

Der rote Faden durch alle fünf: es ist gut in allem Langweiligen und Überprüfbaren.

Was ein Review-Agent strukturell nicht beurteilen kann

Das ist der Abschnitt, den die Doku nicht schreibt, weil es eine Grenze ist und keine Fehlerliste.

Ob das Feature existieren sollte. Der Reviewer liest das Diff und nimmt an, dass das Diff gewollt ist. Er hilft Ihnen, das Falsche korrekt zu bauen, und ist dabei ermutigend. Der wertvollste Kommentar im Code Review war immer "warum machen wir das überhaupt", und kein Review-Agent hinterlässt ihn, weil die Frage außerhalb des Codes liegt.

Ob es zu einer Konvention passt, die niemand aufgeschrieben hat. Ihr Team hat vor achtzehn Monaten nach einem Vorfall aufgehört, das Lazy Loading des ORM zu nutzen. Diese Entscheidung lebt in einem Chat-Kanal, in den Köpfen von zwei Personen und in einem PR-Thread, den niemand wiederfindet. Der Reviewer sieht sauberes, idiomatisches, korrektes Lazy Loading und gibt es frei. Kein Prompt-Problem: Die Information fehlt schlicht.

Ob die Abstraktion in sechs Monaten wehtut. Eine Abstraktion zu beurteilen setzt voraus, zu wissen, was kommt: die zwei Roadmap-Features, für die diese Form nicht taugt, die Integration, die Sie gleich unterschreiben. Der Reviewer sieht ein vernünftiges Interface. Der erfahrene Entwickler sieht das Interface plus das nächste Quartal.

Die Produkt- und Organisationskosten einer Änderung. Dass dieser eine Enterprise-Kunde von diesem Endpunkt abhängt. Dass das Plattform-Team mitten in einer Migration des Service steckt, den Sie gerade angefasst haben. Nichts davon lässt sich mit einem größeren Modell lösen, nur damit, den fehlenden Kontext dorthin zu schreiben, wo der Reviewer ihn lesen kann.

Review-Kategorien, ehrlich bewertet

Nutzen Sie das, um zu entscheiden, was Sie delegieren können.

Das "zuverlässig"-Band ist Arbeit, die Sie von Hand einstellen können. Das "gar nicht"-Band ist das, wofür menschliches Review jetzt da ist.

Ein Review-Durchgang, der sich lohnt

Ein Standard-Review liefert Standard-Funde. Anthropics Doku beschreibt REVIEW.md als reine Review-Anweisungen, die den Agents übergeben werden, die Funde suchen und verifizieren, und die auch die konsultieren, die sie einordnen. Legen Sie das in Ihr Repository-Root und passen Sie es an.

# Review instructions

## What Important means here
Reserve Important for anything that breaks behaviour, leaks data, or blocks a
rollback: incorrect logic, queries not scoped to the caller's tenant, PII in
logs or error messages, migrations that are not backward compatible.
Naming, style, and refactor suggestions are Nit at most.

## Cap the nits
Report at most five Nits per review. If there are more, say "plus N similar
items" in the summary. If everything found is a Nit, open with
"No blocking issues."

## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check
- New API routes have an integration test
- No log line includes an email address, a user ID, or a request body
- Every database query is scoped to the caller's tenant
- A change to a public function updates its callers and its docs

## Verification bar
Behaviour claims need a `file:line` citation, not an inference from a name.

## On re-review
After the first review, suppress new nits and post Important findings only.

Halten Sie sie kurz: Die Doku warnt, dass eine lange REVIEW.md genau die Regeln verwässert, die am wichtigsten sind.

Dann der Durchgang selbst. Bevor Sie ein Review als erledigt akzeptieren, gehen Sie diese Liste durch:

1. Hat es die Fehlerzweige geprüft und nicht nur den Pfad, den der PR beschreibt?
2. Hat es nach Aufrufern von allem gesucht, dessen Signatur sich geändert hat?
3. Hat es gesagt, ob die Tests Verhalten prüfen oder nur die Form?
4. Hat es Doku und Kommentare markiert, die die Änderung unwahr gemacht hat?
5. Hat es etwas gefunden, das CLAUDE.md oder REVIEW.md widerspricht?
6. Was hat es nicht angesehen, und ist genau das der riskante Teil dieser Änderung?

Frage sechs ist die, die sich auszahlt. Wenn Sie lieber von einem Review-Durchgang ausgehen, den jemand bereits abgestimmt hat, statt von einer leeren Datei: Unser Hub mit Code-Review-Skills sammelt die, die wir für diese Aufgabe veröffentlicht haben, installierbar als Claude Code Plugin Marketplace mit /plugin marketplace add mkhalid1/locul-skills. Zu beurteilen, ob ein Review-Skill es wert ist, behalten zu werden, ist ein eigenes Problem, denn mehr Funde ist nicht dasselbe wie bessere Funde. Fünf der 114 Skills dort tragen gemessene Vorher-Nachher-Ergebnisse, sechs weitere wurden getestet und gestrichen, neunzehn wurden zurückgezogen, deshalb lohnt sich die Testmethodik zu lesen, bevor Sie irgendeinem Skill-Verzeichnis trauen, unserem eingeschlossen. Sie schreiben Ihren eigenen? Wie Claude Code Skills funktionieren deckt das Frontmatter ab, mit dem einer zuverlässig feuert.

Der Teil, den niemand konfiguriert: Der Reviewer kennt Ihre Konventionen nicht

Jede Verbesserung oben ist derselbe Zug: dem Reviewer mehr von dem geben, was Ihr Team ohnehin weiß. REVIEW.md schreibt den Schweregrad auf, CLAUDE.md schreibt die Konventionen auf, ein Skill schreibt einen Prozess auf. Alle drei funktionieren, und alle drei laufen gegen dieselbe Wand.

Die Standards, die Ihre Codebasis tatsächlich regieren, stehen nirgendwo geschrieben. Sie stecken im Kopf der Entwicklerin, die seit vier Jahren dabei ist, in einem PR-Kommentar vom März, der einen Streit beendet hat und dann aus dem Sichtfeld gescrollt ist, in dem Postmortem, aus dem eine Regel hervorging, die niemand in einen Lint-Check verwandelt hat. Ein neuer Entwickler lernt sie, indem er über Monate korrigiert wird. Ein Review-Agent nie: Nichts korrigiert ihn, und nichts bleibt bestehen.

Ein Reviewer, der Ihre Konventionen nicht kennt, prüft nicht Ihren Code. Er prüft generischen Code.

Deshalb ist das zweite Review eines Repositories selten besser als das erste. Sie beheben einen Fund, erklären, warum er falsch war, und nächste Woche meldet es denselben Fund erneut. Regeln von Hand in CLAUDE.md zu schreiben hilft und ist der richtige erste Schritt, aber diese Datei hält nur, was jemand aufzuschreiben daran gedacht hat, und sie veraltet in dem Moment, in dem sich eine Entscheidung ändert. Um genau diese Wartungsschleife geht es bei ein KI-Setup aktuell halten, und sie liegt auch unter Claude Code Memory und CLAUDE.md Best Practices.

Genau dafür existiert Locul: eine local-first Desktop-App für macOS und Windows, die aus dem, was Sie ohnehin produzieren, ein zweites Gehirn baut, es aktuell hält, während sich Ihre Entscheidungen ändern, und es Claude Code über MCP bereitstellt. Ändert sich eine Regel, wird die alte Memory als überholt markiert, statt dort stehen zu bleiben und der neuen zu widersprechen.

FAQ

Wie prüfe ich Code mit Claude Code?

Führen Sie /code-review in der Sitzung aus, in der Sie arbeiten. Ohne Argumente prüft es die Commits Ihres Branches, die vor dem Upstream liegen, plus alle nicht committeten Änderungen. Übergeben Sie ein Ziel für alles andere: einen Dateipfad, eine PR-Nummer, einen Branch-Namen oder einen Bereich wie main...my-feature. Ergänzen Sie einen Effort Level, um Sicherheit gegen Abdeckung zu tauschen, --fix, um Funde anzuwenden, oder --comment, um sie am PR zu posten.

Taugt das Claude Code Review in der Praxis etwas?

Es ist in einem Band von Arbeit wirklich gut und in einem anderen nutzlos. Es findet zuverlässig unbehandelte Fehlerpfade, veraltete Aufrufer nach einer Signaturänderung, Inkonsistenzen über ein großes Diff, gängige Sicherheitsmuster und Doku, die die Änderung falsch gemacht hat. Es kann nicht beurteilen, ob das Feature existieren sollte, ob die Änderung eine ungeschriebene Konvention bricht oder ob die Abstraktion schlecht altert. Behandeln Sie es als gründlichen ersten Durchgang, nicht als Freigabe. Die meisten Beschwerden über Rauschen führen zurück auf hohen Effort ohne REVIEW.md.

Wie richte ich automatisches Review für Pull Requests ein?

Ein Organisations-Owner aktiviert Code Review in den Claude-Code-Admin-Einstellungen, installiert die Claude GitHub App, wählt Repositories aus und setzt pro Repo einen Auslöser: einmal nach PR-Erstellung, nach jedem Push oder manuell. Im manuellen Modus starten Sie ein Review, indem Sie @claude review auf oberster Ebene des PR kommentieren, oder @claude review always, um ihn zusätzlich für spätere Pushes zu abonnieren. Um es in Ihrer eigenen Infrastruktur laufen zu lassen, nutzen Sie GitHub Actions oder GitLab CI/CD. Die Kosten skalieren mit PR-Größe und Auslösehäufigkeit.

Was übersieht Claude Code beim Review?

Alles, was Informationen außerhalb des Repositories braucht: ungeschriebene Konventionen, die Roadmap, die entscheidet, ob eine Abstraktion richtig ist, den Kunden, der von dem Endpunkt abhängt, den Sie geändert haben, den Vorfall, aus dem eine Regel hervorging, die niemand aufgeschrieben hat. Nebenläufigkeitsfehler, Performance-Regressionen, die von echtem Traffic abhängen, und Testqualität deckt es ebenfalls nur teilweise ab, denn es sieht eine schwache Assertion, aber nicht, welches Verhalten zählt. Anthropics Doku sagt, dass das gemanagte Review standardmäßig auf Korrektheit zielt statt auf Formatierung oder Testabdeckung, Schweigen dort ist also Geltungsbereich und keine Freigabe.

Wohin als Nächstes

Beginnen Sie bei der Grenze, nicht beim Werkzeug. Entscheiden Sie, welches Band der Tabelle Sie delegieren, schreiben Sie die REVIEW.md, die das festhält, und wählen Sie dann einen Auslöser, den Sie sich leisten können. Das dauert einen Nachmittag und ist der größte Teil des Werts.

Für das größere Bild der Arbeit mit einem Agent an echtem Code lesen Sie, worin ein KI-Coding-Assistent gut und schlecht ist. Und wenn Ihr Reviewer immer wieder Regeln neu aufrollt, die Sie längst geklärt haben, liegt die Lösung oberhalb der Review-Konfiguration: Die Locul-Demo zeigt, wie es aussieht, wenn Ihre Entscheidungen von selbst aktuell bleiben.