Ein schlankes AI-Review-Setup für kleine Repos

Code Review ist die Arbeit, die in vielen Teams am Ende der Kette hängen bleibt. Jeder Agent, der Code schneller schreibt, macht den Review-Stapel größer. Ich habe Code Reviews selbst als Last erlebt, deshalb hat mich ein Artikel aus dem Claude-Code-Team neugierig gemacht: Darin beschreibt Anthropic, wie dort Review auf Maschinen verlagert wird und menschliche Aufmerksamkeit nach Risiko verteilt wird.

Dieses Lab ist ein Setup-Plan, kein Ergebnisbericht. Ich habe das Setup noch nicht auf meinem Repo laufen lassen. Die Zahlen unten stammen aus dem Artikel, sind eine Selbstdarstellung und nicht unabhängig nachprüfbar.

Was der Artikel beschreibt

Anthropic nutzt kein einzelnes Review-Gate, sondern mehrere Schichten:

• Vor dem PR: Tests, Build, Screenshot und ein Subagent mit frischem Kontext prüfen die Änderung.
• Auf jedem PR: ein AI-Review, ein blockierender Security-Review und die CI.
• Danach: eine risikoabhängige menschliche Freigabe, eine Merge Queue mit Feature Flags und ein schneller Rollback.

Laut Artikel haben sich die gemergten PRs von Juni bis September mehr als verdoppelt, während der Anteil an Reverts um über 40 % gesunken ist.

Was für ein kleines Repo übertragbar ist

Nicht alles ist für einen Einzelentwickler sinnvoll. Mehrere Review-Agenten, die über jeden Fund abstimmen, sind aufwendig, und ich weiß noch nicht, welche Teile öffentlich verfügbar sind. Drei Ideen lassen sich dagegen sofort nachbauen.

1. CLAUDE.md für Konventionen

Hier steht, wie das Projekt gebaut, getestet und strukturiert ist. Der Reviewer liest dieselbe Datei wie der Autor-Agent. In meinem Repo gibt es sie schon.

2. REVIEW.md für den Reviewer

Das ist die eigentliche Neuerung für mich. Die Datei sagt dem Reviewer, worauf er pro Codebereich achten soll, was er überspringen darf und wie viel Kleinkram er melden soll. Mein Entwurf für dieses Repo:

# REVIEW.md

## Pflicht
- Jeder Fund nennt Datei und Zeile. Ohne Beleg wird nichts gemeldet.
- Fehlerklasse melden, nicht jede einzelne Zeile.

## Bereiche
- `content/`: Frontmatter vollständig, Dateiname `YYYY-MM-DD-slug.md`, Eintrag in labs.yml oder notes.yml.
- `app/`: Typen korrekt, kein `any` ohne Grund.

## Überspringen
- `pnpm-lock.yaml`, `.output/`, `.nuxt/`

## Ton
- Höchstens drei Nits pro PR.

3. Rundenlimit

Laut Artikel können sich Agent-Autor und Agent-Reviewer endlos beschäftigen, ein PR hatte über 50 Runden. Die Gegenmaßnahmen sind einfach und passen in REVIEW.md:

• maximal drei Runden
• ab der zweiten Runde nur noch der Diff der Änderung
• bereits gemeldete Funde nicht wiederholen

So will ich es testen

Auf einem kleinen eigenen Repo richte ich /code-review, /security-review oder die Claude-Code-GitHub-Action mit CLAUDE.md und REVIEW.md ein. Pro PR notiere ich:

Ausgewertet wird erst, wenn mindestens zehn PRs zusammengekommen sind. Vorher wäre jede Aussage Zufall.

Offene Fragen

• Welche Teile (Abstimmung mehrerer Agenten, Risiko-Klassifikator) sind öffentlich verfügbar und welche nur intern?
• Was kostet ein Review im Deep-Modus pro PR?
• Der Artikel erwähnt keine Circuit Breaker, die bei steigenden Reverts die Freigabe verschärfen. Das müsste ich selbst regeln, zum Beispiel über eine Pflicht-Freigabe von mir bei Änderungen an der CI.

Quelle: Anthropic Engineering, Code Review bei Anthropic