Ein Pull Request mit 47 geänderten Dateien landet in der Review-Warteschlange. Der Reviewer öffnet ihn, sieht den Diff und verbringt die ersten 15 Minuten damit, zu verstehen, was geändert wurde und warum. Welche Dateien sind strukturelle Refactorings? Welche enthalten die eigentliche Logikänderung? Ist die Testabdeckung ausreichend?
Für ein Team, das 10 PRs pro Woche bearbeitet, summiert sich diese Orientierungszeit auf 2,5 Stunden wöchentlich. Code-Review ist wertvoll. Die Orientierungsphase ist es nicht.
Was der Workflow macht
Der PR Review Summarizer Workflow wird bei PR-Events ausgelöst und erzeugt eine strukturierte Review-Zusammenfassung:
-
PR wird geöffnet oder aktualisiert — Wird über GitHub-Webhook ausgelöst, ruft den vollständigen Diff, die PR-Beschreibung, verknüpfte Issues und den Commit-Verlauf ab.
-
AI analysiert den Diff — Die AI liest jede geänderte Datei und erzeugt:
- Zusammenfassung: 2-3 Absätze, die beschreiben, was der PR tut und warum
- Änderungsaufschlüsselung: Dateien nach Zweck gruppiert — Tests, Konfiguration, Kernlogik, Refactoring
- Risikobewertung: Hoch/Mittel/Niedrig mit konkreten Gründen
- Potenzielle Probleme: Spezifische Bedenken, auf die der Reviewer achten sollte
- Testabdeckung: Ob neuer Code entsprechende Tests hat
-
Zusammenfassung als PR-Kommentar — Die Analyse wird als formatierter Kommentar am PR gepostet, den Reviewer sofort sehen.
Die Analyse dauert 30-60 Sekunden.
Eingesparte Zeit
10 PRs pro Woche: Orientierungszeit ohne Zusammenfassung ca. 15 Min/PR = 2,5 Std/Woche, mit Zusammenfassung ca. 3 Min/PR = 30 Min/Woche. Netto-Ersparnis: 2 Stunden/Woche. Die Qualitätsverbesserung ist schwerer zu messen, aber real — Reviewer finden mehr Probleme im kritischen Code.
Was der Mensch weiterhin tut
AI fasst zusammen und markiert, Menschen reviewen. Architekturentscheidungen, Business-Logik-Validierung, Team-Standards und Genehmigungen bleiben Aufgabe des Reviewers. PR-Zusammenfassungen ergänzen das menschliche Review.