KI in der PR-Review-Schleife

Claude gibt Reviews und erhält sie auch. Es überprüft eingehende PRs anhand der Richtlinien der Organisation und geht auf Review-Kommentare zu seinen eigenen PRs ein. Dadurch können sich Engineers in ihrem PR-Review auf das Verhalten konzentrieren, was sich letztlich auf die Beurteilung von Absicht und Risiko reduziert.

Was sich ändert

Erste Schritte

• Voraussetzungen: Eine aktualisierte CLAUDE.md-Datei aus Stufe 3: Build, Skills, falls die Review-Durchgänge schriftliche Richtlinien durchsetzen sollen, und definierte Subagenten.
• Infrastruktur: Ein Repo mit installierter Claude-Integration, entweder der verwaltete Code Review-Dienst, der von einem Owner deiner Claude-Organisation aktiviert wird, oder die claude-code-action, die in deiner eigenen CI läuft, mit Modellaufrufen über Amazon Bedrock, Google Clouds Vertex AI oder Microsoft Foundry, wo nötig (das CI/CD-Play deckt die Bereitstellungsoptionen ab). Branch-Protection-Richtlinien, die die Genehmigung eines Code-Owners erfordern, sind ebenfalls empfehlenswert.

So wird es umgesetzt

1. Der verwaltete Code-Review-Dienst ist der schnellste Einstieg. Ein Owner deiner Claude-Organisation aktiviert ihn und wählt Repositories aus. Führe das Review in deiner eigenen CI mit der claude-code-action aus, wenn du die Kontrolle über die Pipeline benötigst oder API-Aufrufe über deine eigene Cloud-Vereinbarung leiten möchtest (das CI/CD-Play deckt diese technischen Details ab).
2. Der Tech Lead schreibt die Review-Richtlinie als REVIEW.md im Root des Repos, unterteilt in die Durchgänge, die der Organisation wichtig sind: Bugs und logische Fehler; Sicherheit und Schwachstellen; Compliance gegenüber der Spezifikation (spec.md aus dem Requirements-Play), dem Umsetzungsplan (plan.md aus dem Plan-Mode-Play) und den Designprinzipien. REVIEW.md definiert außerdem, was als Important gilt im Gegensatz zu einem Nit, und was übersprungen werden soll.
3. Der Tech Lead legt die menschliche Schwelle fest. Befunde genehmigen oder blockieren einen PR nicht von sich aus, und Branch Protection erfordert weiterhin die Genehmigung eines Code-Owners. Ein Platform Engineer, der Merges anhand von Befunden sperren möchte, kann die Schweregrad-Zählungen auslesen, die der Check-Run als maschinenlesbare Zusammenfassung veröffentlicht.
4. Wenn ein Reviewer oder der Autor @claude in einem Review-Kommentar markiert, geht Claude auf den Kommentar ein und pusht die Korrektur. Der PR-Thread protokolliert sowohl die Anfrage als auch die Änderung. Diese Fix-Schleife läuft über die claude-code-action. Im verwalteten Dienst fordert der Kommentar @claude review stattdessen ein neues Review an. Bei PRs, die Claude selbst eröffnet hat, kannst du noch weiter gehen und Claude den PR bis zum Merge betreuen lassen. Teams verpacken die Schleife in einen benutzerdefinierten Slash-Befehl, der die ungelösten Review-Kommentare und fehlgeschlagenen Checks im PR durchgeht, sie bearbeitet und die Korrekturen pusht, bis der PR grün ist und nur noch auf die Genehmigung des Code-Owners wartet.
5. Review-Befunde fließen zurück in CLAUDE.md. Wenn ein Review einen Fehler zum zweiten Mal markiert, wird die Korrektur als Teil dieses Reviews in CLAUDE.md aufgenommen, und weil das Review CLAUDE.md liest, wird der Fehler ab dem nächsten PR erkannt. Das Review markiert außerdem, wenn eine Änderung CLAUDE.md veraltet gemacht hat.
6. Einmal im Monat feinjustiert der Tech Lead das Setup, indem er Befunde bewertet, damit sich der Reviewer verbessert, und indem er das Nit-Volumen in REVIEW.md begrenzt. Generierte Pfade und alles, was die CI bereits erzwingt, sind ausgeschlossen.

So sieht es aus

REVIEW.md:

# Review instructions
## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles
## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.
## Cap the nits
Report at most five nits per review; summarize the rest as a count.
## Do not report
Generated files under src/gen/ and anything CI already enforces.

Dieses Beispiel zeigt, was der Check-Run für einen Pull Request auflistet, der einem Kundenportal eines Versicherers ein Panel für den Schadensstatus hinzufügt, wobei claims-core das ältere interne System hinter dem Backend des Portals ist:

Der erste Befund existiert nur, weil der Compliance-Durchgang die committete plan.md liest, die ein Reviewer, der nur den Diff betrachtet, nicht geöffnet hätte.

Governance-Überlegungen

Die Aufgabentrennung bleibt gewahrt, weil der Agent, der den Code geschrieben hat, keine Möglichkeit hat, ihn zu genehmigen. Die Review-Richtlinie in REVIEW.md wird auf alle PRs angewendet, und Befunde, Korrekturen, Bewertungen und Genehmigungen werden in der PR-Historie protokolliert, sodass der PR das Audit-Protokoll ist. Die Genehmigung kommt von einem Menschen über Branch Protection, informiert durch die Befunde.

So wird es gemessen

• Frühindikator: Zeit bis zum ersten Review, die auf Minuten sinken sollte, und der Anteil der Review-Kommentare, die gelöst werden, ohne dass ein Mensch den Branch anfasst, wobei die Daten direkt in Git gespeichert werden.
• Spätindikator: Vor dem Merge erkannte Fehler und Schwachstellen im Verhältnis zu denen, die bis in die Produktion durchrutschen, aus der PR-Historie und dem Incident-Tracker.