Rachel Laycock hat einen Artikel geschrieben mit dem Titel Maybe We Shouldn’t Be Reviewing All This Code. Es ist eine Antwort auf Brian Houck, der befürchtet, dass wir mit dem automatisierten Code Review alles verlieren, wofür Review sonst noch da ist: Wissenstransfer, Lernen, gemeinsame Verantwortung, Architekturverständnis.

Ihre Antwort ist einfach, und ich bin einverstanden. Warum warten wir mit diesen Gesprächen überhaupt bis zum Code Review?

Ich möchte ihrem Argument eine Sache hinzufügen. Das Gespräch nach vorne zu ziehen ist richtig. Aber ein Gespräch allein überlebt den Sprint nicht.

Wo ich zustimme

Ihre Liste ist schwer zu widerlegen:

  • Wenn du Alternativen diskutieren willst, tu es vor der Umsetzung, nicht danach.
  • Wenn du Wissenstransfer willst, arbeite im Pair.
  • Wenn du Architektur abstimmen willst, entwerft gemeinsam und haltet die Randbedingungen als Fitness Functions fest.
  • Was sich linten, testen oder scannen lässt, gehört automatisiert.

Ihr Punkt zur Skalierung ist der wichtigste. Wenn ein Agent zehnmal so viel Code erzeugt und jede Zeile weiterhin auf einen Senior wartet, hast du keine zehnmal schnellere Organisation gebaut. Du hast einen Rückstau gebaut.

Sie lässt auch Platz für Review by Exception. Fundamentale Architekturänderungen, sensible Sicherheitsgrenzen, ein grosser Blast Radius, oder ein Team, das schlicht sagt „hier bin ich unsicher“. Dort soll ein Mensch hinschauen. Aber nicht überall sonst, aus Ritual.

Der Punkt, an dem ich nachhake

Ihre Mittel sind Pairing, Mob Programming und gemeinsame Design-Sessions am Whiteboard.

Das ist alles synchron. Das ist alles mündlich. Und nichts davon hinterlässt etwas.

Brian Houcks Sorge war die kognitive Schuld: Die Software wächst, während die Menschen, die dafür verantwortlich sind, immer weniger darüber verstehen, warum sie so funktioniert, wie sie funktioniert. Eine Whiteboard-Session baut diese Schuld nicht ab. Sie erzeugt Verständnis im Raum, an diesem Nachmittag, in den Köpfen der Anwesenden. Ein halbes Jahr später ist das Whiteboard geputzt, zwei der Leute sind weg, und die dritte Person erinnert sich an den Entscheid, aber nicht mehr an den Grund.

Wir ziehen also das Urteil nach vorne und lassen das Ergebnis dann verdunsten.

Nicht nur die Diskussion nach vorne ziehen, sondern das Artefakt

Genau darum ist der AI Unified Process herum gebaut. Das Gespräch findet vor dem Code statt, wie Laycock es vorschlägt, aber es erzeugt etwas Dauerhaftes:

  • Einen Anforderungskatalog statt eines gemeinsamen Gefühls für den Umfang.
  • Use Case Spezifikationen mit Hauptablauf, alternativen Abläufen und Geschäftsregeln, statt eines Whiteboard-Fotos in irgendeinem Chat.
  • Ein Entity Model statt eines Schemas, das nur der Autor erklären kann.
  • Eine Harness-Schicht aus Tests, Fitness Functions und automatisierten Prüfungen, die den Code gegen all das ehrlich hält.

Die Whiteboard-Session findet weiterhin statt. Sie endet nur nicht mehr, wenn die Leute den Raum verlassen.

Was das mit dem Code Review macht

Sobald die Spezifikation existiert, ändert sich die Frage im Review.

Die alte Frage war: Ist dieser Code richtig? Diese Frage ist in der Menge kaum beantwortbar, weil man dafür die Absicht aus dem Diff rekonstruieren muss. Und genau diese Arbeit haben die Agenten unmöglich gemacht.

Die neue Frage ist: Erfüllt diese Implementierung den Use Case, und warum wurde sie so gebaut? Das ist eine viel kleinere Frage. Sie hat einen festen Bezugspunkt. Und sie lässt sich in Minuten beantworten statt in Stunden.

Warum das synchrone Review trotzdem seinen Platz hat

Nach meiner Erfahrung ist das wirksamste Code Review nicht der asynchrone Kommentar im Werkzeug. Es ist der Autor, der den Code jemand anderem laut erklärt.

Der Grund dafür ist, dass Erklären eine zusammenhängende Geschichte verlangt. Beim Schreiben kannst du eine Lücke mit „das passt schon“ überbrücken. Beim Erklären geht das nicht mehr. Meistens findet der Autor das Problem selber, bevor der Zuhörer ein Wort gesagt hat.

Bei Code, den ein Agent geschrieben hat, wird das wichtiger, nicht unwichtiger. Wenn jemand den Code nicht erklären kann, ist genau das das Signal. Entweder hat die Person die Spezifikation nicht verstanden, oder die Spezifikation war zu schwach. Beides ist eine nützliche Erkenntnis, und ein asynchroner Pull Request bringt keine davon ans Licht, weil ein Reviewer bei einem grossen Diff genauso leicht nickt wie der Autor vorher.

Die Spezifikation gibt diesem Gespräch einen Gegenstand. Ohne sie heisst „erklär mir das“ ein Durchgehen des Diffs Zeile für Zeile. Mit ihr heisst es ein Durchgehen eines Use Case.

Die Kehrseiten

Synchrones Review skaliert nicht gratis. Es braucht zwei Leute zur gleichen Zeit, und es hinterlässt keinen schriftlichen Nachweis. In einem regulierten Umfeld, in dem ein Audit Trail gefordert ist, muss das Ergebnis trotzdem irgendwo festgehalten werden.

Und Spezifikationen sind auch nicht gratis. Sie kosten Aufwand am Anfang, sie veralten, wenn sie niemand pflegt, und ein Team, das sie schreibt und dann ignoriert, hat Zeremonie hinzugefügt statt entfernt. Das ist ein echter Fehlermodus, und ich habe ihn gesehen. Die Verteidigung dagegen ist, dass die Spezifikation tragend sein muss. Wenn die Tests auf sie zurückführen und die Agenten aus ihr arbeiten, bleibt sie wahr. Wenn sie nur ein Dokument ist, verrottet sie.

Was ich aus ihrem Artikel mitnehme

Laycock hat recht damit, dass wir zu viel auf den Pull Request geladen haben: Qualitätstor, Sicherheitsprüfung, Architekturreview, Mentoring, Wissenstransfer, Verantwortung. Das hat funktioniert, solange der Mensch die Grenze dafür war, wie schnell Code entsteht. Diese Grenze ist weg.

Ihr Schluss lautet, dass Entwickler Systeme verstehen sollen, nicht Diffs. Da bin ich voll einverstanden. Ich würde nur ergänzen: Das Verständnis eines Systems kann man nicht im kollektiven Gedächtnis eines Teams parken und hoffen, dass es dort bleibt. Es braucht eine schriftliche Form, die das Meeting überlebt.

Zieh das Gespräch nach vorne. Und schreib dann auf, was es entschieden hat.