Claude Code Review als Pull-Request-Gate mit CLAUDE.md und REVIEW.md nutzen

Anthropic hat Code Review für Claude Code am 9. März 2026 veröffentlicht, mit einer Zahl, bei der jede Engineering-Leitung kurz schlucken dürfte: Bei Anthropic war der Code-Output pro Engineer innerhalb eines Jahres um 200% gewachsen, und Review wurde zum Flaschenhals (Anthropic). Das ist die eigentliche Geschichte. AI-Coding hat Review-Arbeit nicht abgeschafft. Es hat nur den Druckpunkt verschoben.

Die sinnvolle Antwort lautet nicht: „Lass Claude seine eigenen Hausaufgaben abnicken.“ So baut man sich eine höfliche Bug-Fabrik. Die sinnvolle Antwort ist, Claude Code Review zu einem wiederholbaren PR-Gate zu machen, mit Regeln, an die dein Team wirklich glaubt.

Anthropics Setup-Dokumentation macht das inzwischen praktikabel. Ein Reviewer kann eine Review auslösen, indem er @claude review kommentiert, und Code Review liest CLAUDE.md-Dateien im Repository plus eine REVIEW.md auf Root-Ebene. Verstöße gegen CLAUDE.md werden als Nit-Level-Findings behandelt, und Claude kann sogar einen PR markieren, der CLAUDE.md veraltet macht (Claude Help Center). REVIEW.md ist der Ort für reine Review-Regeln, inklusive des Beispiels von Anthropic: „jede neue API-Route braucht einen Integrationstest.“

Dieser eine Satz ist der Drehpunkt. Hör auf, AI-Reviewer zu bitten, „vorsichtig zu sein“. Gib ihnen Repository-Gesetz.

Eine Ablaufskizze, in der ein Pull-Request-Diff in Claude Code Review läuft, sich in parallele Review-Agenten aufteilt und C prüft

Das Problem: AI hat PR-Reviews lauter gemacht

Die Community-Debatte ist chaotisch, weil beide Seiten recht haben.

Im Hacker-News-Thread zu Claude Code Review drückten Entwickler auf Preis, Nutzen und die unangenehme Tatsache, dass ein AI-Anbieter einen Reviewer für AI-generierten Code verkauft. Ein Kommentator zeigte auf Anthropics eigene Zahlen zu großen PRs und las sie als Warnsignal für die Qualität agentischer Entwicklung, während andere argumentierten, dass ein gründliches zweites Augenpaar genau der Punkt ist, an dem das Tool seinen Wert liefert (Hacker News).

Reddit hat die praktischere Version derselben Debatte. In einem Thread fragte ein Entwickler, ob Leute Claude-generiertem Code wirklich genug vertrauen, um Reviews zu überspringen, weil Claude manchmal Code schreibt, den sie nicht verstehen. Die Antworten waren direkt: reviewen, validieren, Änderungen klein halten und nicht so tun, als würde Delegation Verantwortung verschwinden lassen (Reddit). In einem anderen Thread diskutierten Leute, separate AI-Agenten zu nutzen, um Claudes Output zu reviewen, während sie die Review selbst weiterhin gegen die Codebase prüfen (Reddit).

Meine Einschätzung: Claude Claude-geschriebenen Code reviewen zu lassen ist okay, solange du es nicht als unabhängiges Urteil behandelst. Behandle es wie einen sehr schnellen, sehr wörtlichen Junior-Reviewer mit riesigem Kontext und ohne Ownership. Es soll langweilige Auslassungen finden, Cross-File-Inkonsistenzen, fehlende Tests, Security-Fußangeln, veraltete Doku und Stellen, an denen ein menschlicher Reviewer wahrscheinlich drüberfliegt.

Es sollte nicht der finale Approver sein.

Anthropic sagt das direkt. Code Review approved PRs nicht und blockiert sie auch nicht von allein. Bestehende Review-Workflows bleiben intakt (Claude Help Center). Das „Gate“ ist also ein Team-Gate: keine menschliche Freigabe, bis Claude gelaufen ist, Important Findings behoben oder explizit waived sind und der PR-Autor die repo-spezifischen Regeln adressiert hat.

Das ist langweilig. Gut so. Langweilige Gates verhindern Incidents.

Das Setup: Zwei Markdown-Dateien, zwei Aufgaben

Claude Code Review hat zwei relevante Memory-Flächen.

CLAUDE.md ist geteilter Projektkontext. Sie gilt allgemein für Claude Code Sessions, nicht nur für Reviews. Anthropic empfiehlt, sie für Commands, Konventionen, kurze Architekturhinweise, harte Constraints und bekannte Stolperfallen zu nutzen. Sie empfehlen außerdem, sie signalstark zu halten, grob unter 200 Zeilen, weil sie in den Kontext geladen wird, auch wenn Prompt Caching die wiederholten Token-Kosten in Enterprise-Sessions reduziert (Claude Help Center).

REVIEW.md ist anders. Sie liegt im Root des Repositorys und ist nur für Reviews gedacht. Anthropics Code-Review-Dokumentation sagt, dass ihr Inhalt als High-Priority-Instructions in jeden Review-Agenten injiziert wird und dass sie der Ort ist, um Severity, Nit-Menge, Skip-Regeln, repo-spezifische Checks, Verifikationsstandards und Re-Review-Verhalten zu steuern (Claude Code Docs).

So teile ich es auf:

File	Zweck	Gute Regeln	Schlechte Regeln
`CLAUDE.md`	Projektgedächtnis für alle Claude-Arbeiten	Build-Commands, Architektur, „Zod für Request-Validation nutzen“	Lange Historien, vage Vorlieben, doppelte API-Doku
`REVIEW.md`	PR-Review-Policy	„Neue API-Routen brauchen Integrationstests“	Generische „schreib sauberen Code“-Ratschläge
CI-Konfig	Deterministische Durchsetzung	Typecheck, Unit-Tests, Lint, Migration-Checks	LLM-only Checks für Dinge, die ein Compiler beweisen kann

Pack stabilen Kontext in CLAUDE.md. Pack Review-Druck in REVIEW.md. Pack alles Deterministische in CI.

Eine kompakte Vergleichstabelle mit drei Spalten namens CLAUDE.md, REVIEW.md und CI, die Kontextregeln und Review zeigt

Ein echtes Gate für API-Routen

Angenommen, ein Backend-Team liefert ständig Routen mit Happy-Path-Unit-Tests, aber ohne Integrationsabdeckung. Menschliche Reviewer erwischen das manchmal. Claude-generierte PRs machen es schlimmer, weil der Agent gut darin ist, plausiblen Handler-Code zu produzieren, und schlecht darin, sich an team-spezifische Review-Narben zu erinnern.

Beginne mit CLAUDE.md:

# Project conventions

- API routes live in `src/routes`.
- Integration tests live in `tests/integration`.
- Use `requireAuth()` on non-public routes.
- Validate request bodies with Zod schemas from `src/schemas`.
- Run `pnpm test:integration` before marking API work complete.

Dann füge eine REVIEW.md auf Root-Ebene hinzu:

# Code Review Rules

Treat these as Important unless stated otherwise.

## API routes

If a PR adds or changes a file under `src/routes/**`:
- Flag missing integration test coverage in `tests/integration/**`.
- Flag routes without explicit auth, unless the route is listed as public.
- Flag request bodies that are not validated with a Zod schema.

Do not accept unit tests as a substitute for route-level integration tests.

## Evidence bar

For every Important finding, cite the changed file and the missing or conflicting evidence.
If the claim depends on a convention, cite this REVIEW.md rule.

Der letzte Abschnitt zählt. LLM-Reviewer können selbstbewussten Unsinn produzieren. Ein Evidence-Zwang zwingt die Review, ein Finding an eine Datei, eine Zeile oder eine explizite Policy zu binden. Das eliminiert False Positives nicht, aber es verschiebt die Form der Review von „Vibes“ zu „zeig es mir.“

Jetzt fügt ein PR Folgendes hinzu:

// src/routes/billing.ts
router.post("/billing/plan", async (req, res) => {
  const result = await updatePlan(req.body.planId);
  res.json(result);
});

Ein guter Kommentar von Claude Code Review sollte ungefähr so klingen:

Important: src/routes/billing.ts adds a new POST route without visible auth.
Important: request body reads req.body.planId without schema validation.
Important: no matching integration test was added under tests/integration/**.

Der menschliche Reviewer entscheidet weiterhin. Vielleicht ist Auth-Middleware höher im Router angewendet. Vielleicht lebt der Integrationstest in einer generierten Contract-Suite. Okay. Das Gate hat seinen Job gemacht, wenn es diese Diskussion vor dem Merge erzwungen hat.

Auslösen, ohne Geld zu verbrennen

Anthropic bietet drei Trigger-Modi fürs Repository: einmal nach PR-Erstellung, nach jedem Push oder manuell. Manuell heißt: keine Kosten, bis jemand @claude review kommentiert; danach lösen weitere Pushes automatisch Reviews für diesen PR aus (Claude Help Center).

Für die meisten Teams würde ich nicht mit „nach jedem Push“ starten. Anthropic sagt, Code Review dauert im Schnitt etwa 20 Minuten und kostet normalerweise $15 bis $25 pro Review, skaliert nach PR-Größe und Komplexität (Anthropic). Das ist billig im Vergleich zu einem Production Incident. Es ist teuer im Vergleich zu ESLint.

Nutze ein gestuftes Gate:

Jeder PR läuft durch normales CI.
Riskante PRs bekommen @claude review.
Große PRs, Auth-Änderungen, Payments-Änderungen, Migrationen und öffentliche API-Änderungen brauchen Claude Review vor menschlicher Freigabe.
Wiederhole Claude Review nach größeren Änderungen, nicht nach jedem Tippfehler-Fix.
Menschen tragen die finale Freigabe.

Eine schlanke GitHub-PR-Checklist macht das Gate explizit:

## AI Review Gate

- [ ] CI is green.
- [ ] `@claude review` has run, or this PR is exempt.
- [ ] Important findings are fixed or explained.
- [ ] If this PR changes conventions, `CLAUDE.md` is updated.
- [ ] If this PR changes review policy, `REVIEW.md` is updated.

Wenn du Claude lieber in deinem eigenen Workflow laufen lässt, zeigen Anthropics GitHub-Actions-Dokumente anthropics/claude-code-action@v1 und eine Code-Review-Plugin-Konfiguration, mit der üblichen Warnung, GitHub Secrets für API-Keys zu verwenden (Claude Code Docs). Dieser Weg gibt dir mehr CI-Kontrolle. Der Managed-Code-Review-Weg gibt dir den tieferen Multi-Agent-Reviewer, den Anthropic beschreibt.

Verwechsle die beiden nicht. Das eine ist programmierbare Automation. Das andere ist ein bezahlter, tief bohrender Reviewer.

Ein Entscheidungsbaumdiagramm für Review-Trigger mit Zweigen für kleinen PR, riskanten PR, großen PR und wiederholte Pushes, endend

Der Trick: Lass Claude den Vertrag reviewen, nicht den Stil

Schlechte REVIEW.md-Dateien lesen sich wie Glückskekse:

Please ensure the code is clean, maintainable, secure, and well tested.

Das produziert Brei.

Gute REVIEW.md-Dateien kodieren Narben:

## Database migrations

Flag as Important if:
- A migration adds a non-null column without a default on an existing table.
- A migration backfills data without batching.
- Application code starts reading a new column before the migration is deployed.

Skip:
- Formatting comments in generated Prisma client files.

Hier wird AI Review nützlich. Sie ersetzt nicht den Geschmack deines Senior Engineers. Sie spielt die institutionelle Erinnerung des Teams bei jedem PR wieder ab.

Ein paar Regeln, die gut funktionieren:

## Re-review behavior

On the first review, report Important and Nit findings.
On later reviews of the same PR, suppress new Nits unless they are directly caused by the latest push.

## Test policy

Flag missing tests only when the changed behavior is observable through a stable public interface.
Do not request snapshot tests for purely visual copy changes.

## Security policy

Flag any new endpoint that:
- Accepts user input without validation.
- Performs authorization by trusting a user-provided account ID.
- Logs tokens, session IDs, API keys, or full request bodies.

Was fehlt, ist auffällig: „Mach den Code elegant.“ Menschen können in Reviews über Eleganz streiten. Claude sollte Verträge prüfen.

Was die Threads übersehen

Die HN- und Reddit-Debatten kreisen immer wieder um eine Frage: Sollte AI AI-Code reviewen?

Falsche Frage.

Die richtige Frage lautet: Welche Teile von Review bist du bereit, explizit zu machen?

Wenn deine Review-Kultur in den Köpfen von Senior Engineers lebt, wird Claude Code Review laut und willkürlich wirken. Wenn deine Review-Kultur als Repository-Regeln aufgeschrieben ist, wird sie zum Multiplikator. CLAUDE.md sagt Claude, wie das Projekt funktioniert. REVIEW.md sagt Claude, was dein Team nicht mergen wird.

Das beantwortet auch die Beschwerde über „Dokumentation für Claude“. Ja, Entwickler schreiben jetzt Doku für einen Agenten. Das klingt albern, bis du merkst, dass diese Doku auch Onboarding-Material, Review-Policy und Incident-Prävention ist. Eine gute CLAUDE.md ist auch für Menschen eine bessere „so funktioniert dieses Repo“-Datei.

Die scharfe Kante ist Accountability. Wenn Claude den Bug übersieht, hast du ihn trotzdem gemerged. Wenn Claude einen Bug erfindet, musst du ihn trotzdem ablehnen. Wenn Claude seinen eigenen Output reviewt, brauchst du trotzdem unabhängige Signale: Tests, Typsysteme, statische Analyse, Observability und einen Menschen, der die Änderung versteht.

Nutze Claude Code Review als Gate, nicht als Richter. Lass es jedes Mal die nervigen Fragen stellen:

Wo ist der Integrationstest?
Wo wird Auth erzwungen?
Hat dieser PR CLAUDE.md falsch gemacht?
Ist diese generierte Datei einen Kommentar wert?
Ist dieses Finding durch Code belegt oder nur eine Ahnung?

Das reicht, damit es sich bei den richtigen PRs bezahlt macht.

Probier dasselbe Setup mit Claude Fable 5 auf OneHop, drop-in, und starte mit $10 gratis.

Weiterlesen: Erste Schritte mit Claude Fable 5.