Claude Code PR-Review: Diffs vor der Review schneller und sicherer prüfen

Warum PR-Reviews oft länger dauern

PR-Reviews dauern selten ewig, weil der Code „schwierig“ ist. Sie dauern so lange, weil der Reviewer aus einem Diff, das nur Änderungen zeigt, nicht die Absicht, die Risiken und die Auswirkungen rekonstruieren kann.

Eine kleine Änderung kann versteckte Abhängigkeiten treffen: ein Feld umbenennen und ein Bericht bricht, ein Default ändern und das Verhalten verschiebt sich, eine Bedingung anpassen und die Fehlerbehandlung ändert sich. Die Review-Zeit wächst, wenn der Reviewer überall klicken muss, die App lokal starten muss und Nachfragen stellen muss, nur um zu verstehen, was der PR erreichen soll.

Es gibt außerdem ein menschliches Musterproblem. Menschen überfliegen Diffs auf vorhersehbare Weise: Wir konzentrieren uns auf die „Haupt“-Änderung und übersehen die langweiligen Zeilen, in denen Bugs versteckt sind (Grenzprüfungen, Null-Behandlung, Logging, Aufräumen). Wir lesen auch oft, was wir erwarten zu sehen, sodass Copy-Paste-Fehler und invertierte Bedingungen durchrutschen können.

Eine gute Vorab-Prüfung ist kein Urteil. Sie ist ein schneller, strukturierter zweiter Blick, der zeigt, wo ein Mensch langsamer werden sollte. Das beste Ergebnis ist:

• eine leicht verständliche Zusammenfassung dessen, was sich geändert hat
• spezifische Risikopunkte (Dateien, Funktionen, Annahmen)
• Lesbarkeitsnotizen (Benennungen, verwirrende Kontrollflüsse)
• Korrektheitsbedenken (Logik, Fehlerbehandlung, Datenkonsistenz)
• Randfälle, die getestet werden sollten (Eingaben, Zeit, Berechtigungen, leere Zustände)

Was es nicht tun sollte: den PR „freigeben“, Anforderungen erfinden oder Laufzeitverhalten ohne Belege raten. Wenn der Diff nicht genug Kontext enthält (erwartete Eingaben, Einschränkungen, Aufruferverträge), sollte die Vorab-Prüfung genau das sagen und auflisten, was fehlt.

KI-Hilfe ist am stärksten bei mittelgroßen PRs, die Geschäftslogik oder Refactorings betreffen, wo Bedeutung verloren gehen kann. Sie ist schwächer, wenn die richtige Antwort tief organisationsspezifisches Wissen erfordert (Legacy-Verhalten, Produktions-Performance-Eigenheiten, interne Sicherheitsregeln).

Beispiel: Ein PR, der „nur die Pagination aktualisiert“, verbirgt oft Off-by-One-Probleme, leere Ergebnisse und nicht übereinstimmende Sortierung zwischen API und UI. Eine Vorab-Prüfung sollte diese Fragen aufwerfen, bevor ein Mensch 30 Minuten damit verbringt, sie neu zu entdecken.

Was man Claude in einer Vorabprüfung aufträgt

Behandle Claude wie einen schnellen, pingeligen Erstprüfer, nicht wie die Person, die entscheidet, ob der PR ausgeliefert wird. Ziel ist es, Probleme früh zu entdecken: verwirrenden Code, versteckte Verhaltensänderungen, fehlende Tests und Randfälle, die man vergisst, wenn man nah an der Änderung dran ist.

Gib ihm, was ein fairer menschlicher Reviewer benötigen würde:

• das Ziel des PR (1 bis 3 Sätze)
• was auf keinen Fall kaputt gehen darf (API-Form, Abwärtskompatibilität, Performance-Budget, Sicherheitsregeln)
• spezielle Einschränkungen oder Trade-offs (Deadlines, partielle Rollouts)
• die relevanten Diff-Hunks, mit genug umgebendem Code, um die Absicht zu verstehen

Wenn der PR einen bekannten Hochrisikobereich berührt, sag das gleich vorneweg (Auth, Abrechnung, Migrationen, Concurrency).

Fordere dann Ergebnisse an, die du umsetzen kannst. Eine starke Anfrage sieht so aus:

• Fasse in einfachem Englisch zusammen, was sich geändert hat.
• Markiere Lesbarkeitsprobleme (Benennung, Struktur, Überraschungen, inkonsistente Muster).
• Identifiziere Korrektheitsrisiken (Null-Behandlung, Fehlerpfade, Off-by-One, Datenformfehler).
• Liste Randfälle und Fehler-Modi, die getestet werden sollten (Timeouts, Retries, leere Eingaben, partielle Updates).
• Schlage fehlende Tests vor und was jeder Test beweist.
• Erzeuge eine kurze Reviewer-Checkliste und 5 bis 10 „Fragen an den Autor“ vor dem Merge.

Halte den Menschen in der Verantwortung, indem du Klarheit über Unsicherheiten erzwingst. Bitte Claude, Funde als „aus dem Diff sicher“ vs. „muss bestätigt werden“ zu kennzeichnen und die genauen Zeilen zu zitieren, die jeden Punkt ausgelöst haben.

Bereite den Diff und Kontext vor, bevor du promptest

Claude ist nur so gut wie das, was du ihm zeigst. Wenn du einen riesigen Diff ohne Ziel oder Einschränkungen einfügst, bekommst du allgemeine Ratschläge und verpasst die echten Risiken.

Fang mit einem konkreten Ziel und Erfolgskriterien an. Zum Beispiel: „Dieser PR fügt Rate-Limiting zum Login-Endpoint hinzu, um Missbrauch zu reduzieren. Er darf die Antwortstruktur nicht ändern. Er muss die durchschnittliche Latenz unter 50 ms halten."

Behalte danach nur das, was relevant ist. Wenn 20 Dateien geändert wurden, aber nur 3 die Logik enthalten, konzentriere dich auf diese. Füge Kontext hinzu, wenn ein Ausschnitt irreführend wäre, wie Funktionssignaturen, wichtige Typen oder Konfigurationen, die das Verhalten ändern.

Sei schließlich explizit bei den Test-Erwartungen. Wenn du Unit-Tests für Randfälle willst, einen Integrationstest für einen kritischen Pfad oder einen manuellen UI-Check, sag es. Wenn Tests absichtlich fehlen, erkläre warum.

Ein einfaches „Context-Pack“, das gut funktioniert:

• PR-Ziel: was sich ändert, was Benutzer sehen, was verbessert werden soll
• Relevante Diff-Hunks: nur Schlüsseldateien, mit genug umgebendem Code
• Harte Einschränkungen: Performance-Budgets, Kompatibilitätsanforderungen, Sicherheits-/Datenschutzregeln
• Test-Erwartungen: was abgedeckt sein muss, was hinzugefügt wurde, wie es ausgeführt wird
• „Darf nicht ändern“-Punkte: öffentliche API-Verträge, Datenbankschema, UX-Verhalten, Logging/Audit-Format

Schritt-für-Schritt: ein wiederholbarer Vorabprüfungs-Flow

Eine gute Claude Code PR-Review funktioniert als enger Loop: gib gerade genug Kontext, erhalte strukturierte Notizen zurück und verwandle sie dann in Maßnahmen. Sie ersetzt keine Menschen. Sie fängt einfache Fehler bevor ein Kollege viel Zeit mit Lesen verbringt.

Der 5-Pass-Flow

Verwende bei jeder Review dieselben Durchläufe, damit die Ergebnisse vorhersehbar bleiben:

1. Erkläre die Änderung in einfachen Worten. Bitte Claude, zusammenzufassen, was der PR macht, welche Dateien sich geändert haben und was wahrscheinlich der Grund für die Änderung ist. Wenn er es nicht einfach erklären kann, braucht der PR wahrscheinlich eine klarere Beschreibung oder einen kleineren Umfang.
2. Prüfe zuerst die Korrektheit. Suche nach Logikfehlern, gebrochenen Annahmen und stillen Verhaltensänderungen (Defaults, Fehlerbehandlung, Berechtigungen, Zeitzonen, Off-by-One).
3. Scanne nach fehlenden Fällen. Denke wie ein Nutzer und wie die Produktion: leere Eingaben, Nulls, Retries, partielle Fehler, Concurrency, Rückwärtskompatibilität.
4. Bewerte Lesbarkeit und Wartbarkeit. Identifiziere verwirrende Namen, lange Funktionen, duplizierte Logik, unklare Kommentare und kleine Refactors, die zukünftige Reviews reduzieren.
5. Entwirf Review-Kommentare mit Hinweisen. Gruppiere Kommentare nach Datei und füge Funktionsnamen oder ein zitiertes Snippet hinzu, damit ein Mensch die Stelle schnell findet.

Nachdem du Notizen erhalten hast, verwandle sie in ein kurzes Merge-Gate:

Merge-Checkliste (kurz halten):

• Tests decken das neue Verhalten und mindestens einen Randfall ab
• Fehler werden konsistent behandelt (und bei Bedarf geloggt)
• Keine Breaking-Change ohne klaren Migrationspfad
• Benennung und Struktur passen zum umliegenden Code
• Riskante Teile haben einen Rollback-Plan

Schließe mit 3 bis 5 Fragen ab, die Klarheit erzwingen, wie „Was passiert, wenn die API eine leere Liste zurückgibt?“ oder „Ist das unter konkurrierenden Anfragen sicher?"

Benutze ein einfaches Rubrik (Lesbarkeit, Korrektheit, Randfälle)

Claude ist am hilfreichsten, wenn du ihm eine feste Linse gibst. Ohne Rubrik kommentiert er oft das, was als Erstes auffällt (häufig Stil-Nits) und kann den einen riskanten Grenzfall übersehen.

Eine praktische Rubrik:

• Lesbarkeit: klare Namen, einfacher Ablauf, kleine Funktionen, Kommentare, die das Warum erklären, kein toter Code oder übrig gebliebenes Debugging.
• Korrektheit: Schlüsselinvarianten sind durchgesetzt, Fehler konsistent behandelt, Null-/Leere-Werte sicher, Grenzen korrekt (Off-by-One, Rundung).
• Randfälle: leere/große Eingaben, fehlende optionale Felder, Zeitzonen und Sommerzeit, Retries, die doppelte Writes riskieren, Konkurrenzbedingungen.
• Sicherheit und Datenschutz: Auth-Checks an der richtigen Stelle, keine Geheimnisse im Code/Logs, Logs leaken keine Tokens oder sensible Nutzlasten.
• Kompatibilität und Rollout-Sicherheit: ältere Clients und gespeicherte Daten brechen nicht, Migrationen sind sicher, Rollback-Plan existiert.

Wenn du promptest, fordere einen kurzen Absatz pro Kategorie an und bitte um „höchstes Risiko zuerst“. Diese Reihenfolge hält Menschen fokussiert.

Prompt-Vorlagen, die nützliche Review-Notizen liefern

Verwende eine wiederverwendbare Basisvorlage, damit Ergebnisse über PRs hinweg gleich aussehen. Füge die PR-Beschreibung dann den Diff an. Wenn Verhalten nutzerseitig ist, ergänze erwartetes Verhalten in 1–2 Sätzen.

You are doing a pre-review of a pull request.

Context
- Repo/service: <name>
- Goal of change: <1-2 sentences>
- Constraints: <perf, security, backward compatibility, etc>

Input
- PR description:
<...>
- Diff (unified diff):
<...>

Output format
1) Summary (max 4 bullets)
2) Readability notes (nits + suggested rewrites)
3) Correctness risks (what could break, and why)
4) Edge cases to test (specific scenarios)
5) Reviewer checklist (5-10 checkboxes)
6) Questions to ask the author before merge (3-7)

Rules
- Cite evidence by quoting the relevant diff lines and naming file + function/class.
- If unsure, say what info you need.

Für Hochrisiko-Änderungen (Auth, Zahlungen, Berechtigungen, Migrationen) füge explizites Failure- und Rollback-Denken hinzu:

Extra focus for this review:
- Security/privacy risks, permission bypass, data leaks
- Money/credits/accounting correctness (double-charge, idempotency)
- Migration safety (locks, backfill, down path, runtime compatibility)
- Monitoring/alerts and rollback plan
Return a “stop-ship” section listing issues that should block merge.

Bei Refactors mache „kein Verhaltenswechsel“ zur harten Regel:

This PR is a refactor. Assume behavior must be identical.
- Flag any behavior change, even if minor.
- List invariants that must remain true.
- Point to the exact diff hunks that could change behavior.
- Suggest a minimal test plan to confirm equivalence.

Wenn du einen schnellen Überblick willst, füge ein Limit wie „Antworte in unter 200 Wörtern“ hinzu. Wenn du Tiefe willst, bitte um „bis zu 10 Findings mit Begründung."

Verwandle die Ausgabe in eine Reviewer-Checkliste

Claude’s Notizen werden nützlich, wenn du sie in eine kurze Checkliste verwandelst, die ein Mensch abarbeiten kann. Wiederhole nicht den Diff. Erfasse Risiken und Entscheidungen.

Teile Items in zwei Gruppen, damit das Thread nicht in Präferenz-Debatten ausartet:

Must-fix (Merge blockieren)

• Korrektheit: erwartetes Ergebnis ist in einem Satz beschrieben und stimmt mit dem Ticket überein
• Randfälle: Null/Leere Eingaben und Fehlerpfade sind klar behandelt (oder werden abgelehnt)
• Datensicherheit: Writes und Migrationen sind sicher für bestehende Daten und alten Code
• Tests: mindestens ein Test deckt das Hauptverhalten ab und einer deckt den risikoreichsten Fehler
• Beobachtbarkeit: Logs/Metriken reichen zur schnellen Fehlersuche (Request-ID, User-ID, Job-ID)

Nice-to-have (Follow-ups)

• Lesbarkeit: benenne das verwirrendste Identifier um oder füge einen kurzen „Warum“-Kommentar hinzu
• Konsistenz: passe an bestehende Patterns für Fehler, Benennung und Dateilayout an
• Performance: weise auf Hot-Path-Änderungen hin und ob sie beim aktuellen Traffic relevant sind
• Docs: aktualisiere Inline-Dokumentation, wenn eine neue Option/Flag hinzugefügt wurde

Erfasse außerdem Rollout-Bereitschaft: sicherste Deploy-Reihenfolge, worauf nach Release zu achten ist und wie du die Änderung rückgängig machst.

Fragen, die vor dem Mergen zu stellen sind

Eine Vorab-Prüfung hilft nur, wenn sie mit einer kleinen Menge Fragen endet, die Klarheit erzwingen.

Verhalten und Korrektheit

• Welche benutzerseitigen Verhaltensänderungen gibt es und was muss gleich bleiben?
• Wenn dies „kein Verhaltenswechsel“ ist: Welche Belege zeigen, dass Ausgaben identisch sind?
• Was ist der wahrscheinlichste Produktionsfehler und wo würde er sich zeigen (UI, API, Daten)?
• Welche Annahmen macht der Code über Eingaben, Reihenfolge, Zeit oder Netzwerkaufrufe?
• Werden Fehler verschluckt oder in stille Defaults verwandelt?

Randfälle, Tests und Betrieb

• Was sind die schlimmsten realen Eingaben (leer, groß, malformed, duplicate) und was soll passieren?
• Welcher übliche Flow könnte das zweimal auslösen (Retries, Doppelklick, Hintergrundjobs) und ist das sicher?
• Welcher Test beweist das Hauptverhalten und welcher Test deckt den risikoreichsten Randfall ab?
• Wenn ein Test fehlt: ist er schwer zu schreiben oder ist der Code schwer zu testen?
• Was braucht Ops: nützliche Logs, Metriken, Alerts, Config-Defaults und Rollback-Schritte?

Wenn du diese Fragen nicht in klaren Worten beantworten kannst, pausiere den Merge und verschmäler den Scope oder füge Belege hinzu.

Häufige Fallen (und wie man sie vermeidet)

Die meisten Fehler sind Prozess-Probleme, nicht Modell-Probleme.

• Riesige Diffs ohne Fokus einreichen. Bitte um Review für 1–3 riskante Bereiche und füge nur die relevanten Hunks plus benötigte Signaturen ein.
• Absicht und erwartetes Verhalten überspringen. Ohne Ziel driftet die Review ab. Füge zwei Zeilen hinzu: was sich ändert und was nicht.
• Auf zu selbstbewusste Vermutungen vertrauen. Fordere Zitate zurück zum Diff. Wenn es keine Belege zitiert, behandle es als Hypothese.
• In Stilfragen versinken. Forder „Must-fix“ vs. „Nice-to-have“ und begrenze Stil-Notes.
• Team-Standards ignorieren. Wenn dein Team Konventionen hat (early returns, Fehler-Typen, Logging-Format), schließe sie mit ein.

Wenn ein PR einen neuen Checkout-Endpoint hinzufügt, füge nicht den ganzen Service ein. Füge den Handler, Validierung, DB-Write und Schema-Änderungen ein. Dann schreibe: „Ziel: doppelte Belastungen verhindern. Nicht-Ziele: Namens-Refactor.“ Du bekommst weniger Kommentare, und die Kommentare sind leichter zu überprüfen.

Ein realistisches Beispiel: Vorabprüfung eines kleinen PRs

Ein kleines, realistisch wirkendes PR: Füge ein „display name“-Feld zu einem Einstellungen-Screen hinzu. Es berührt die Validierung (Server) und UI-Texte (Client). Es ist klein genug, um es zu überblicken, aber enthält trotzdem Stellen, wo Bugs versteckt sind.

Hier sind die Diff-Snippets, die du einfügen würdest (plus 2–3 Sätze Kontext wie erwartetes Verhalten und verwandte Tickets):

- if len(name) == 0 { return error("name required") }
+ if len(displayName) < 3 { return error("display name too short") }
+ if len(displayName) > 30 { return error("display name too long") }

- <TextInput label="Name" value={name} />
+ <TextInput label="Display name" value={displayName} helperText="Shown on your profile" />

Beispiele für Findings, die du zurückhaben willst:

• Lesbarkeit: „displayName“ vs. „name“ ist in mehreren Dateien gemischt. Wähle einen Begriff, damit zukünftige Änderungen keine mentale Übersetzung erfordern.
• Korrektheit: Der Server validiert die Länge, der Client jedoch nicht. Nutzer können 1–2 Zeichen eingeben und sehen den Fehler erst nach dem Absenden.
• Randfall: Leerzeichen-only Strings bestehen die len(displayName)-Prüfung, sehen aber trotzdem leer aus. Vor der Validierung trimmen.

Verwandle das in eine Checkliste:

• Benennung ist konsistent über API, DB-Felder und UI-Labels
• Client-seitige Prüfungen stimmen mit Server-Regeln überein (min/max, required)
• Eingaben werden getrimmt (und Unicode/Emoji-Verhalten ist akzeptabel)
• Fehlermeldungen sind klar und zwischen Server und UI abgestimmt

Schnelle Checks, Messung und nächste Schritte

Eine Claude Code PR-Review endet am besten mit ein paar schnellen Checks:

• Verhalten: was ändert sich für einen Nutzer und was darf nicht ändern
• Tests: was ist abgedeckt, was fehlt, was könnte flaky sein
• Logs und Fehler: sind Fehler klar und Meldungen nutzbar
• Performance: neue Loops, N+1-Queries, große Payloads, zusätzliche Netzaufrufe
• Sicherheit: Validierung, Auth-Checks, Secrets, riskante Defaults

Um zu prüfen, ob es sich lohnt, tracke zwei einfache Metriken für 2–4 Wochen: Review-Zeit (öffnet bis erste sinnvolle Review und öffnet bis Merge) und Nacharbeit (Follow-up-Commits nach Review oder wie viele Kommentare Code-Änderungen erforderten).

Standardisierung schlägt perfekte Prompts. Wähle eine Vorlage, verlange einen kurzen Kontext-Block (was sich ändert, warum, wie zu testen) und einigt euch auf eine Definition von „done“.

Wenn dein Team Features durch Chat-basiertes Development baut, kannst du denselben Workflow in Koder.ai anwenden: generiere Änderungen, exportiere den Quellcode und hänge dann die Vorab-Checkliste an den PR, damit die menschliche Review auf die riskantesten Teile fokussiert bleibt.