Seit Teams häufiger mit Claude Code, Codex, Cursor oder Copilot arbeiten, beobachte ich eine Verschiebung von der Implementierung, die immer schneller wird, hin zum Review.
Das ist logisch: Wenn ein Agent in kurzer Zeit viel Output erzeugt, wächst der Hebel an mehreren Stellen gleichzeitig. Mehr Code in weniger Zeit heißt auch: mehr Scope, mehr implizite Annahmen, mehr Möglichkeiten, dass eine scheinbar kleine Änderung in Nachbarbereiche ausstrahlt. Der eigentliche Qualitätsentscheid fällt dann oft nicht beim Prompten, sondern im Pull Request.
Viele Teams merken das an derselben Stelle. Ein Diff sieht zunächst vernünftig aus. Die Tests laufen. Dann beginnt das Review, und plötzlich tauchen Fragen auf, die vorher niemand sauber beantwortet hat:
- Warum wurde diese Datei überhaupt mit geändert?
- War dieses Refactoring Teil der Aufgabe?
- Worauf basiert diese Annahme?
- Prüfen die Tests den eigentlichen Fall oder nur irgendeinen Happy Path?
- Wer hätte diesen Diff guten Gewissens freigeben sollen?
Sobald KI-gestützte Entwicklung im Teamalltag ankommt, reicht die implizite Review-Kultur vieler Teams nicht mehr aus. Die Regeln, die früher im Kopf der erfahrenen Entwickler saßen, müssen sichtbarer werden.
Warum das Review jetzt mehr Gewicht bekommt
Bei manuell geschriebenem Code war der Flaschenhals oft die eigentliche Implementierung. Der Review-Prozess war natürlich auch damals wichtig, aber das Tempo der Änderung lag näher am Tempo des menschlichen Schreibens. Ein größerer Diff war meist schon ein Warnsignal, bevor überhaupt ein Pull Request geöffnet wurde.
Mit Agenten verschiebt sich das.
Ein Entwickler kann in kurzer Zeit mehrere Lösungsansätze durchspielen, sich Tests generieren lassen, Teile eines Refactorings anstoßen und nebenbei noch Dokumentation aktualisieren. Das ist wertvoll. Es bedeutet aber auch, dass mehr Entscheidungen vor dem Review schon in den Diff hineingeflossen sind. Je klarer das Team dann prüft, desto ruhiger wird die Arbeit.
Anders gesagt: KI erhöht den Bedarf an Urteilsfähigkeit im Team. Das betrifft nicht nur den Autor eines Diffs, sondern genauso die Reviewer.
Daher halte ich eine Review-Checkliste für eines der ersten Dokumente, die ein Team bei KI-gestützter Entwicklung gemeinsam festhalten sollte. Ich meine damit keine Liste mit 30 Punkten, die anschließend im Wiki verstaubt. Eine kurze, klare Checkliste reicht oft völlig aus, wenn sie tatsächlich benutzt wird.
Vier Muster, an denen KI-PRs im Review hängenbleiben
Bevor wir zur Checkliste kommen, lohnt sich ein Blick auf die häufigsten Reibungspunkte.
1. Der Scope wächst still mit
Das klassische Beispiel: Der eigentliche Bugfix betrifft drei Zeilen, der Diff hat 180. Zusätzlich wurden Imports sortiert, ein Helper extrahiert, zwei Tests umgebaut und eine Nachbardatei „gleich mit aufgeräumt“. Nichts davon ist automatisch falsch. Für Reviewer wird aber unklar, worüber sie gerade eigentlich entscheiden sollen. Das ist kein neues Problem bei Reviews, kann jetzt aber deutlich stärker auftreten.
2. Annahmen bleiben unsichtbar
Agenten füllen Lücken mit plausiblen Vermutungen. Genau darin liegt ihre Stärke. Genau darin liegt auch das Risiko.
Wenn im Diff nicht erkennbar ist, welche Annahmen getroffen wurden, reviewt das Team am Ende Code, ohne die zugrunde liegende Entscheidung zu sehen.
3. Tests sehen sauber aus und prüfen trotzdem zu wenig
Grüne Tests beruhigen. Sie sagen aber wenig, wenn sie am eigentlichen Risiko vorbeigehen. Viele KI-generierte Tests prüfen vor allem, ob der aktuelle Output zum neuen Code passt. Für das Team ist interessanter, ob der relevante Edge Case abgedeckt ist, ob eine Regression wahrscheinlich entdeckt würde und ob das Verhalten fachlich richtig beschrieben wurde.
4. Verantwortung verschwimmt
Wenn ein Agent große Teile eines Diffs vorbereitet, wird die Frage „Wer steht hier eigentlich mit seinem Namen drauf?“ wichtiger. Im besten Fall ist die Antwort klar: der Entwickler, der die Aufgabe gesteuert, gelesen, getestet und eingeordnet hat. Im schlechtesten Fall fühlt sich niemand wirklich verantwortlich, weil der Diff „vom Tool kam“. Genau dort leidet die Review-Kultur.
Die Checkliste
Für Teams hat sich aus meiner Sicht eine Checkliste mit sechs Punkten bewährt. Sie ist kurz genug, um in ein PR-Template zu passen, und konkret genug, um echte Diskussionen zu verkürzen.
1. Ist der Zweck der Änderung in einem Satz beschreibbar?
Ein Reviewer sollte nach wenigen Sekunden verstehen, worum es geht. Nicht in Marketing-Sprache oder im Stil eines Commit-Romans, sondern in einem klaren Satz.
Beispiel:
„Fix für fehlerhafte Bestandsberechnung bei Teileingängen im Lager-Endpoint, inklusive passender Regressionstests.“
Wenn dieser Satz fehlt oder während des Reviews mehrfach umformuliert werden muss, ist das oft ein Zeichen für zu breiten Scope. Teams sparen hier viel Zeit, wenn sie sich angewöhnen, den Zweck einer Änderung vor dem Review explizit zu benennen.
2. Ist der Scope sichtbar begrenzt?
Hier prüft das Team, welche Dateien und Bereiche die Änderung betreffen durfte und welche bewusst ausgeschlossen waren.
Ich halte das für einen der größten Hebel überhaupt. Wer regelmäßig mit KI arbeitet, sollte Scope im Prompt und im Pull Request sichtbar machen. Das kann so knapp sein wie:
- In scope:
warehouse/views.py,warehouse/tests/test_views.py - Out of scope: Models, Migrations, Serializer, Utility-Funktionen
Diese Information hilft dem Agenten bei der Ausführung und dem Team im Review. Wer einen Diff nur gegen das Ziel „läuft irgendwie“ prüft, bekommt mehr Überraschungen. Wer gegen einen klar markierten Rahmen prüft, erkennt Abweichungen schneller. Mehr dazu habe ich im Artikel „Reviewbare Diffs“ beschrieben.
Wenn du dir anschaust, wie Claude Code Aufgaben an Subagents übergibt, siehst du dasselbe Muster auch dort: Scope und Ausschlüsse sind explizit.
3. Sind Annahmen und Risiken sichtbar gemacht?
Ein guter KI-Diff enthält nicht nur Code, sondern auch Kontext.
Welche Annahme wurde getroffen? Wo könnte der Change unerwartete Nebenwirkungen haben? Welche Stelle verdient beim Testen besondere Aufmerksamkeit? Ein kurzer Risiko-Hinweis reicht oft schon.
Beispiel:
„Annahme: Teileingänge werden immer mit positiver Menge gespeichert. Mögliche Regressionsquelle: parallele Buchungen im selben Zeitfenster.“
Solche Sätze wirken klein. Für Reviewer sind sie Gold wert, weil sie den Blick auf das Wesentliche lenken.
Wenn du das weiterdenkst, kannst du daraus auch formalisierte Entscheidungsnotizen machen: etwa Architecture Decision Records (ADRs) oder Annahmenlisten aus Product Requirement Documents.
4. Prüfen die Tests den relevanten Fall?
Ich frage in Reviews nicht zuerst: „Gibt es Tests?“
Ich frage: „Prüfen diese Tests genau das, woran die Änderung scheitern könnte?“
Das ist ein Unterschied.
Ein KI-Agent schreibt schnell Tests, die formal ordentlich aussehen. Für Teams zählt, ob sie die fachlich heikle Stelle erfassen. Wird der beschriebene Bug reproduziert? Wird der erwartete Zustand nach der Änderung konkret überprüft? Würde der Test bei einer typischen Regression wirklich rot werden?
Gerade bei KI-generierten Tests lohnt sich dieser strenge Blick, weil die Form oft überzeugender ist als die inhaltliche Schärfe.
5. Bleibt der Diff für einen Menschen reviewbar?
Reviewbar heißt für mich: Ein erfahrener Entwickler kann den Change in vernünftiger Zeit lesen, den Zweck verstehen und die Risiken gedanklich verfolgen.
Wenn dafür erst mehrere Dateien rekonstruiert, zusätzliche Refactorings ausgefiltert und Seiteneffekte auseinanderdividiert werden müssen, ist der Diff zu groß oder falsch geschnitten.
Teams dürfen hier ruhig konsequent sein. „Bitte in zwei Pull Requests aufteilen“ ist kein pedantischer Einwand. Es ist eine Schutzmaßnahme für Qualität und Tempo.
Eine leichte, mechanische Aufteilung, die Kent Beck in Tidy First nahelegt: Trenne Refactoring — also Strukturänderungen bei konstantem Verhalten — von der eigentlichen Feature-Änderung. So bereitest du den Code auf die Änderung vor, kannst zeigen, dass noch alles funktioniert, und hältst den eigentlichen Change klein. „Make the change easy, then make the easy change.“
6. Ist klar, wer die Änderung verantwortet?
Der letzte Punkt ist kulturell wichtig.
Ein Pull Request braucht einen menschlichen Verantwortlichen (im Sinne von ‚ownership‘ im Englischen). Jemand hat den Agenten gesteuert, den Output gelesen, Tests geprüft, Ausschlüsse gesetzt und dann entschieden, dass dieser Stand reviewbar ist. Diese Verantwortung sollte im Team nie verwischen.
Sobald die Haltung entsteht „Das Tool hat es halt so gemacht“, verliert das Team die Kontrolle über seinen Qualitätsmaßstab. Gute Review-Routinen ziehen an dieser Stelle eine klare Linie: Der Agent produziert Vorschläge und Code. Die Verantwortung bleibt beim Entwickler und beim Team.
„Claude hat gesagt …“ ist kein gutes Argument, sondern ein Anzeichen für geistige Bequemlichkeit.
So kann die Checkliste im Alltag aussehen
Viele Teams brauchen für den Einstieg keine große Einführung, sondern ein simples Template, das in jedem Pull Request wieder auftaucht. GitHub hat ein Pull-Request-Template-Feature genau dafür. Das kann zum Beispiel so aussehen:
## Zweck
## In scope / Out of scope
## Annahmen / Risiken
## Tests
## Reviewer-Check
- Zweck klar
- Scope eingehalten
- Tests relevant
- Diff reviewbar
- Verantwortung klar
Das Entscheidende ist, dass Autoren und Reviewer dieselben Fragen regelmäßig sehen.
Wie Teams die Checkliste verankern
Eine Checkliste wirkt durch Wiederholung.
Ich würde sie auf drei Arten im Team verankern:
Im PR-Template
Der naheliegendste Ort. Jeder Pull Request läuft ohnehin dort durch. Wenn Scope, Annahmen und Tests an dieser Stelle abgefragt werden, sinkt die Hürde zur konsequenten Nutzung.
Im Team-Playbook
Gerade bei KI-gestützter Entwicklung lohnt sich eine kurze Teamseite mit den Regeln, auf die sich alle geeinigt haben. Niemand liest sie täglich zur meditativen Einstimmung auf den Tag, aber mit ihrer Hilfe entsteht im Review kein Streit darüber, ob diese Maßstäbe überhaupt gelten.
In den ersten zwei Wochen aktiv referenzieren
Neue Routinen setzen sich selten von allein durch. In den ersten Wochen sollte mindestens eine Person im Team die Checkliste aktiv im Review erwähnen. „Bitte Scope ergänzen.“; „Welche Annahme steckt dahinter?“; „Der Diff ist für einen Schritt zu groß.“ Solche kurzen Hinweise machen aus einem Dokument eine Praxis.
Was sich nach ein paar Wochen verändert
Wenn Teams diese Art von Review-Checkliste sauber anwenden, …
-
… werden Pull Requests ruhiger. Nicht zwangsläufig kleiner, aber klarer. Reviewer wissen schneller, worauf sie schauen sollen.
-
… verbessern sich die Prompts rückwirkend. Sobald Autoren wissen, welche Fragen später im Review gestellt werden, formulieren sie Scope, Ausschlüsse und Erwartung an den Output schon am Anfang präziser.
-
… lernt das Team schneller. Jeder gute oder zurückgewiesene Diff liefert Material für die nächste Runde. Die Checkliste macht diese Lernschleife sichtbar.
Genau das gefällt mir an dem Thema: Gute Reviews bremsen KI-gestützte Entwicklung nicht aus. Sie machen sie belastbar.
Wenn dein Team mit KI-Tools arbeitet und Reviews unruhiger werden, ist eine kurze gemeinsame Checkliste oft der einfachste Guardrail. Sie ersetzt keine Urteilsfähigkeit. Sie macht sie im Team sichtbar. Und genau so wird aus schneller Agenten-Ausgabe ein Teamablauf, der im Alltag funktioniert.