Code Review für Agents
Moderne Coding-Agenten sind in der Lage, in sehr kurzer Zeit eine erstaunliche Menge an Code zu erzeugen. Das kann überwältigend sein, und die Versuchung, den Code einfach ungeprüft zu übernehmen, ist groß. Wir möchten ein paar Tricks mit dir teilen, wie du den Überblick behalten kannst, denn wir sind fest davon überzeugt, dass KI-generierter Code weiterhin eine menschliche Überprüfung braucht.
)
TLDR – zu lang, nicht gelesen
- Besorge dir eine Oberfläche, mit der du die Git-Änderungen zwischen dem ersten AI-Commit und dem aktuellen Working Directory vergleichen kannst.
- Gehe alle Änderungen durch und wenn dir etwas nicht gefällt, füge einen Kommentar hinzu.
- Sage deinem Agenten, er soll die Kommentare finden, sie zu Aufgaben gruppieren und daran arbeiten.
- Wiederhole das Ganze, bis du mit den Änderungen zufrieden bist.
Lass uns mit einem Beispiel starten
Um einen echten Anwendungsfall zu haben, habe ich meinem bevorzugten Agenten (GitHub Copilot mit GPT-5.4) folgenden Prompt gegeben:
Ich möchte eine sehr kleine Todo-App. Gehe dabei in den folgenden Schritten vor und stelle sicher, nach jedem Schritt zu committen.
- Git initialisieren und ein Readme hinzufügen
- Ein npm-Projekt initialisieren und Vite/React/TypeScript über die Vite-CLI einrichten
- Tailwind einrichten
- Eine erste Version der Todo-App erstellen
- Persistenz über LocalStorage hinzufügen
Wir brauchen vorerst keine Tests.
Das ergibt die folgende Commit-Historie:
)
Eine Todo-App in nur 5 Commits!
Wie du siehst, haben wir jetzt eine kleine Todo-App in 5 Commits. Für mich ergibt es sehr viel Sinn, den Agenten mehrere Commits erstellen zu lassen, da er so einen größeren Arbeitsblock erledigen kann, während du trotzdem in der Lage bist, den Gedankengang des Agenten nachzuvollziehen. Du musst dem Agenten nicht einmal die konkreten Schritte vorgeben. Solange du ihm sagst, dass er seine Arbeit in kleinere Abschnitte aufteilen soll, solltest du ein ähnliches Ergebnis erzielen können.
Die Git-UI
Kommen wir nun zum Review-Teil. Für mich ist das Wichtigste, auf einer höheren Ebene SEHEN zu können, was der Agent gemacht hat. Dafür nutze ich die Git Graph VSCode-Erweiterung. Damit kannst du diesen großen Graphen öffnen, der dir eine gute Übersicht über die Projekthistorie gibt. Und wenn du einen Commit oder einen Bereich von Commits auswählst (mit cmd + Klick), kannst du die geänderten Dateien in einer übersichtlichen Baumstruktur sehen:
)
Sieh dir die genauen Änderungen einer Datei an.
Wenn du auf eine der Dateien klickst, erhältst du die Diff-Ansicht, die zeigt, was dieser spezifische Commit in der Datei verändert hat.
Nun könntest du jede einzelne Datei durchgehen, dir den Diff anschauen und einen großen Prompt mit all deinen Anmerkungen schreiben. Ein Problem dabei ist jedoch, dass du nicht wirklich mit dem Code interagieren kannst, da die beiden Versionen (vorher und nachher) nicht gleichzeitig in deinem Working Directory existieren. Das bedeutet: TypeScript ist nicht verfügbar, „Go to Definition“ funktioniert nicht richtig, und du kannst keine schnellen Inline-Änderungen vornehmen, wie z. B. einen Commit direkt fixen.
Ein besserer Prozess
Für mich ist die perfekte Lösung für diese Probleme der Vergleich zwischen einem Commit und dem Working Tree. Um das mit Git Graph zu erreichen, brauchst du mindestens eine nicht gestagte Änderung in irgendeiner Datei. Normalerweise füge ich einfach temporär einen Buchstaben in die README.md-Datei ein. Dann erlaubt dir Git Graph, jeden Commit mit deinem aktuellen Dateisystem zu vergleichen, indem du zuerst auf den Commit VOR den zu überprüfenden Commits klickst und anschließend mit cmd + Klick die oberste Zeile auswählst. Das sollte zu folgender Ansicht führen:
)
Das zeigt alle Änderungen, die nach Commit a20a4179 erfolgt sind.
Jetzt kannst du die geänderten Dateien durchgehen, „Go to Definition“ verwenden, über Variablen hovern, um ihren Typ zu sehen, und Änderungen vornehmen.
Was mir inzwischen am besten gefällt, ist, Kommentare für den Agenten zu hinterlassen:
)
Wir haben einen ganz normalen Pull-Request-Kommentar direkt im Code hinterlassen.
Jetzt gehen wir alle geänderten Dateien seit dem initialen Commit durch, schauen uns die Änderungen an, die der Agent vorgenommen hat, und hinterlassen Kommentare an den Stellen, an denen wir Anmerkungen haben. Wir können sogar Fragen hinterlassen, die der Agent beantworten soll, zum Beispiel: „Mir gefällt nicht, dass wir hier ein useEffect verwenden – können wir das anders lösen?“
Sobald wir die Kommentare hinzugefügt haben, bleibt nur noch, einen letzten Prompt zu schreiben:
Gehe den Code durch und finde Kommentare, die mit „AGENT-TODO“ markiert sind. Scanne sie, gruppiere sie nach Themen, beantworte alle Fragen (wenn möglich mit Vorschlägen) und schlage einen Implementierungsplan mit Teilschritten vor, den du dann in mehreren Commits umsetzen kannst.
Ein reguläres Code-Review mit einem agentischen Entwickler
Am Ende war mein Ziel, einen Prozess zu finden, der das Beste aus beiden Welten kombiniert: den Agenten den Code schreiben zu lassen und gleichzeitig weiterhin die Kontrolle zu behalten und das Ergebnis nach meinen Vorstellungen zu beeinflussen. Indem ich Kommentare direkt im Code hinterlasse und selbst kleine Änderungen vornehmen kann, kann ich einen deutlich langsameren Pull-Request-Prozess überspringen – vor allem, weil die VSCode-Oberfläche für Code-Reviews viel besser geeignet ist als so etwas wie GitHub.
Wenn du jetzt noch einen Schritt weitergehen willst, kannst du die erstellten Aufgaben an das Task-Management-System deiner Wahl übergeben und eine Ralph Loop die Umsetzung übernehmen lassen. Aber das ist ein Thema für einen anderen Artikel.
)
)
)
)
)
)
)
)
)