- Im Zeitalter von KI, die Code schreibt, muss sich die Review-Methode für Pull Requests (PRs) grundlegend ändern; der aktuelle Review-Prozess passt nicht zu KI-Coding-Workflows
- Wenn ein Reviewer fragt: „Warum wurde das so gemacht?“, fragt der Entwickler erneut die KI und fügt die Antwort per Copy-paste ein — ein ineffizienter Ablauf, bei dem der Mensch nur als Vermittler (middleman) dient
- Das Entscheidungsprotokoll (decision log) der KI sollte zusammen mit dem Code in die Versionsverwaltung aufgenommen werden, damit Reviewer den Kontext direkt prüfen können
- Ein Workflow, bei dem die KI Reviewer-Kommentare direkt empfängt und Patches sowie Antworten automatisch erzeugt, ist mit einer Kombination aus GitHub/GitLab-Webhooks und einem MCP-Server bereits heute möglich
- Auch Designdokumente und Architekturdiagramme sollten in von LLMs parsebaren Formaten wie Markdown oder Mermaid in die Versionsverwaltung aufgenommen werden; „Kontext ist König“
Probleme von Code Reviews im KI-Zeitalter
- Bei PR-Reviews kommen auf Fragen Antworten zurück, die wie von einer KI generiert wirken, weil tatsächlich die KI den Code geschrieben hat
- Auf die Frage „Warum wurde diese Bibliothek gewählt?“ kann der menschliche Entwickler nicht antworten; stattdessen fragt er erneut die KI und kopiert die Antwort weiter
- Vor der KI fragte man direkt den Entwickler (Autor des Codes), nicht dessen Manager — daher muss der Vermittler verschwinden
- Alle Autoren des Codes sollten am Review beteiligt sein; für Review-Fragen nachträglich einen separaten KI-Agenten Gründe rückerschließen zu lassen, ist ein völlig falscher Ansatz
Warum ein Entscheidungsprotokoll nötig ist
- Wenn man einen Menschen nach dem „Warum?“ fragt, fragt man nach internen Gedankengängen, die nicht im PR enthalten sind
- Der Chain-of-Thought der KI ist extern auditierbar (externally auditable), und auch die Aufzeichnungen der Interaktionen mit der KI sind auditierbar; deshalb muss dieser Kontext in Review und Versionsverwaltung aufgenommen werden
- Es ist nicht nötig, alle im PR-Erstellungsprozess erzeugten Tokens zu committen; inspiriert vom Episoden-Konzept (episodes) von Random Labs sollten nur Transkripte erfolgreicher Tool-Aufrufe und Schlussfolgerungen aufgenommen werden
- Das skaliert auch in einer Agent-Swarm-Umgebung; dabei werden Entscheidungsprotokolle vor dem PR verknüpft und abschließend formatiert
Grenzen von Inline-Kommentaren
- Änderungen an Quelldateien erfordern selbst dann eine erneute Ausführung der Build-Pipeline (Linting, Kompilierung, Tests), wenn nur Kommentare geändert werden
- Entscheidungs-Transkripte sind deutlich umfangreicher als das, was in gewöhnlichen Inline-Kommentaren zulässig ist
- Bestehende Kommentare erklären, wie der Code aktuell funktioniert, nicht den Weg, der zu dieser Entscheidung geführt hat
KI-integrierter Review-Workflow
- Wenn ein Reviewer einen Kommentar hinterlässt, sollte die KI des Entwicklers ihn direkt empfangen und Patches sowie Antworten automatisch erzeugen können
- Mit einer Kombination aus GitHub/GitLab-Webhooks und einem MCP-Server ist das bereits heute umsetzbar
- Ähnlich wie bei Devin AI oder Claude Code via GitLab Duo
- Es lässt sich so konfigurieren, dass der Entwickler zuerst die Erlaubnis der KI einholt, oder so, dass die KI selbst entscheidet und sofort handelt
- Auch menschliche Entwickler können weiterhin eigenständig kommentieren und Änderungen vornehmen
- Das kann das Problem, dass Review-Kommentare erst Stunden oder Tage später — oder gar nicht — umgesetzt werden, deutlich verringern
Tool-Anforderungen für Reviewer
- Reviewer sollten PRs wie eine Codebasis durch direkte Fragen an eine KI prüfen können
- Dafür ist es entscheidend, dass das Entscheidungsprotokoll zusammen mit dem Code eingecheckt wird
- Die bestehende PR-Oberfläche sollte erhalten bleiben, ergänzt um ein integriertes Fenster zum Dialog mit Codex oder Claude, ähnlich wie in einer IDE-Entwicklungsumgebung
- Es gibt dafür noch kein wirklich sauberes Tool; es wäre wünschenswert, wenn jemand so etwas bauen würde
- Bei unbekannten Bibliotheken, ungewohnten Sprachen oder Best Practices im Diff sollte man privat per KI Fragen stellen und Antworten einholen können, bevor entschieden wird, ob ein Code-Review-Kommentar nötig ist
- Wenn ein Kommentar nötig ist, ist das ein Signal, dass es im Entscheidungsprotokoll eine Lücke (gap) gibt; dann sollte das Protokoll vor der PR-Freigabe aktualisiert werden
Die Bedeutung von Designdokumenten und Kontext
- In einem KI-integrierten Review wird es für Reviewer auch viel einfacher, direkt Patches vorzuschlagen
- Designdokumente, Entscheidungsprotokolle (decision records) und Architekturdiagramme sollten in von LLMs parsebaren Formaten wie Markdown oder Mermaid zur Versionsverwaltung hinzugefügt werden
- „Kontext ist König (Context is king)“
10 Kommentare
Der Grund, warum PRs tot sind, scheint weniger am PR selbst zu liegen als an der schlampigen Kommunikation von Vibe-Codern.
In welchem Flow etwas umgesetzt wurde, welche anderen Methoden es gab und warum sie nicht gewählt wurden, warum sich
package.lockändern musste. Sind das nicht alles Dinge, die man zuerst erklären sollte?Wenn man es einfach in die PR-Beschreibung schreiben könnte, wirken eher die Coder entbehrlich, die einen unbedingt erst danach fragen lassen.
Sehe ich genauso. Früher hatte ein PR noch etwas von dem Gefühl, dass ich für das von mir geschaffene Ergebnis selbst verantwortlich bin,
doch das PR eines Vibe Coders wirkt eher wie: „Ich habe keine Ahnung, was ich da überhaupt gebaut habe, aber ein Ergebnis gibt es jedenfalls, also bewerte du es und finde die Probleme.“
Ich stimme zu.
Es entwickelt sich zuerst zu einer Form, in der man darüber spricht und später keine Verantwortung mehr übernimmt.
Sehe ich genauso. Es ist wirklich nervig.
Dem stimme ich zu.
In einem PR werden gleich 500 Dateien geändert, und die Einreichenden beschweren sich dann noch, dass das Review nicht innerhalb von 30 Minuten erledigt wurde. In die Beschreibung schreiben sie fünf oder sechs Zeilen und fertig – soll man das dann einfach glauben und freigeben...?
Tests alle gemacht?
Ja
Gut, dann streng dich weiter an
Warum wird ständig behauptet, alles sei tot?
Wenn das so weitergeht, sterben wir alle!
Es gibt inzwischen zu viele Artikel mit Titeln der Art, dass irgendetwas „tot“ sei,
und das wirkt mit der Zeit ziemlich ermüdend.
Ich finde auch, man sollte endlich damit aufhören, ständig alles für tot zu erklären.
„Tot; es lebe“
Solche Artikel gibt es inzwischen wirklich zu viele. Aber ich erkenne an, dass KI gerade alles verändert.