Review von KI-generierten Änderungen

Review von KI-generierten Änderungen

0:00 Im neunten Modul kommt der Moment, auf den alles bisher zuläuft: die Prüfung einer fertigen Änderung. Und ich beginne mit einer Umstellung, die viele überrascht. Die erste Frage am Diff lautet nicht, ob der Code gut ist. Sie lautet, ob er den Auftrag erfüllt — und nur ihn. Das ist eine andere Frage, sie kommt zuerst, und ohne den Auftrag daneben lässt sie sich gar nicht beantworten.

0:23 Dann prüft man gegen den eigenen Geschmack statt gegen eine Vereinbarung.

Review von KI-generierten Änderungen

0:28 Damit schließen wir den zweiten Tag ab, und zwar wieder mit einer Tagesübung — dem problematischen Pull Request. Alles aus diesem Tag kommt dort zusammen: der Kontext aus Modul sechs, die Testbeurteilung aus Modul sieben, die automatischen Prüfungen aus Modul acht. Und Sie werden am Ende eine Entscheidung treffen müssen, die viele scheuen: nachbessern oder verwerfen.

0:49 Damit ist der Verifikationsteil des Seminars abgeschlossen, und der dritte Tag wendet sich dem Bestand zu.

Diff-first statt Ergebnis

0:55 Fangen wir mit der verbreitetsten Art an, generierten Code zu prüfen — und sie ist zugleich die schwächste. Zusammenfassung lesen, Ergebnis ausprobieren, übernehmen. Das fühlt sich nach Prüfung an und beantwortet nur die halbe Frage. Sehen wir uns an, welche Hälfte dabei fehlt, und warum genau dort die teuren Probleme sitzen.

1:15 Zusammenfassung und Ausprobieren beantworten beide nur, ob das Gewünschte eingetreten ist. Sie beantworten nicht, was sonst noch geschehen ist. Und genau dort liegen die Probleme, die später teuer werden. Der Grund ist simpel: Eine Zusammenfassung wird von demselben Werkzeug geschrieben, das die Änderung gemacht hat — sie berichtet über die Absicht, nicht über das Ergebnis.

1:37 Der Diff ist die einzige vollständige Darstellung dessen, was sich tatsächlich verändert hat. Alles, was daneben passiert ist, steht nur dort und nirgendwo sonst. Vier Beispiele für das, was durchrutscht, und alle vier sind aus dem Leben. Die nebenbei geänderte Konfiguration wirkt erst im Betrieb, dann aber überall. Die entfernte Prüfung fällt nicht auf, weil das Verhalten stimmt — bis der Randfall kommt, den die Prüfung abgefangen hätte.

2:03 Die zusätzliche Abhängigkeit bringt Lieferkette, Lizenz und Pflege auf Dauer mit. Und die umbenannte öffentliche Funktion trifft Leute, die gar nicht wissen, dass hier gearbeitet wurde. Keine dieser vier Zeilen steht in einer Zusammenfassung. Alle vier stehen im Diff. Und jetzt die Einschränkung, die mir wichtig ist: Diff-first funktioniert nur mit Vorarbeit. Ohne sauberen Ausgangszustand vor dem Agentenlauf lässt sich nichts zuordnen.

2:30 Ohne kleinen Auftrag übersteigt der Diff die Prüfkapazität aus Modul vier — die zweihundert bis vierhundert Zeilen. Und ohne automatisierte Formatierung versteckt sich der Inhalt im Rauschen. Ohne diese drei ist Diff-first ein frommer Wunsch, keine Methode. Das ist der Grund, warum die Module vier, fünf und acht vor diesem stehen.

Auftragstreue und Nicht-Ziele prüfen

2:51 Kommen wir zur ersten Frage am Diff, und sie ist nicht die nach der Codequalität. Sie ist die nach der Auftragstreue. Dafür brauchen Sie den Auftrag mit seinen Nicht-Zielen daneben — sonst prüfen Sie gegen den eigenen Geschmack. Drei Abweichungen kommen dabei regelmäßig vor, und die dritte ist die gefährlichste. Drei Zeilen, und die rechte Spalte erklärt jeweils, warum sie durchrutschen.

3:14 Die Änderung tut weniger als beauftragt — der schwierige Fall wurde stillschweigend ausgelassen, und das Ergebnis wirkt trotzdem vollständig. Sie tut mehr — die Zusatzverbesserungen stehen im Diff und sind für sich genommen richtig, was das Ablehnen erschwert. Und die dritte: Sie tut etwas anderes, weil die Aufgabe umgedeutet wurde. Das ist die häufigste und am schwersten zu erkennende Variante, denn das Ergebnis ist in sich stimmig.

3:39 Sie erinnern sich an Modul eins: Überzeugungskraft und Richtigkeit sind entkoppelt. Nur der Vergleich mit dem Ziel bringt es ans Licht. Der erste Punkt ist der handwerkliche: ohne den Auftrag daneben prüfen. Dann urteilen Sie über Geschmack, und das ist im Review die schlechteste Gesprächsgrundlage. Der zweite ist die Folge davon — ohne die Nicht-Ziele fällt das Zuviel gar nicht auf. Der dritte betrifft die Vollständigkeit: Man liest sie am Umfang ab statt am schwierigen Fall.

4:08 Und der vierte ist der aus Modul eins bekannte, hier in seiner gefährlichsten Form: eine stimmige Lösung für eine richtige halten.

Überflüssiges erkennen

4:16 Nach der Auftragstreue kommt der Ballast. Generierte Änderungen tragen ihn typischerweise mit, und das hat einen ökonomischen Grund, der neu ist. Wir sehen uns vier Fragen an, mit denen sich das Überflüssige zügig einsammeln lässt — und einen Grundsatz, der die Prüfung erheblich abkürzt. Denn was nichts kostet, entsteht in Mengen, die niemand angefordert hat.

4:38 Jedes zusätzliche Element kostet dauerhaft, während der Nutzen meist hypothetisch bleibt. Der Grundsatz, der die Prüfung abkürzt, lautet deshalb: Was nicht gebraucht wird, kommt raus — und die Beweislast liegt beim Hinzufügen, nicht beim Streichen. Diese Haltung ist heute wichtiger als früher, und der Grund ist rein ökonomisch: Das Hinzufügen kostet nichts mehr.

4:59 Früher hat der Aufwand des Schreibens die Menge ganz von allein begrenzt. Dieser Regler ist weg. Wer diese Umkehrung nicht ausdrücklich vornimmt, sammelt bei jeder Änderung ein wenig mehr an. Vier Fragen, die schnell gestellt sind. Ist eine Datei entstanden, die niemand angefordert hat — eine Konfiguration, eine Hilfsklasse, eine zusätzliche Ebene?

5:21 Kam eine Abhängigkeit hinzu, und ersetzt sie etwas, das die Standardbibliothek oder der vorhandene Bestand schon kann? Steht hinter einer neuen Abstraktion genau eine Umsetzung — dann ist es Verpackung, wie wir in Modul drei gesehen haben? Und wurden Dateien angefasst, die mit der Aufgabe nichts zu tun haben? Vier Fragen, zwei Minuten, und Sie haben den größten Teil des Ballasts.

5:44 Der erste Punkt ist die verbreitetste Nachgiebigkeit: eine überflüssige Ebene behalten, weil sie ja niemandem weh tut. Sie tut weh, nur verteilt — jeder künftige Leser bezahlt einen kleinen Teil. Der zweite betrifft Abhängigkeiten, die Vorhandenes ersetzen; darauf kommen wir in Modul elf noch einmal zurück. Der dritte ist tückisch, weil er gut begründet klingt: Zusatzdateien durchwinken, weil sie für sich genommen ordentlich sind.

6:09 Und der vierte ist die Umkehrung der Beweislast — wenn Sie das Streichen begründen müssen, haben Sie verloren.

Fachliche und sicherheitsrelevante Risiken

6:16 Jetzt zur inhaltlichen Prüfung. Und hier empfehle ich ausdrücklich, entlang fester Kategorien vorzugehen statt frei zu lesen. Der Grund ist unangenehm einfach: Beim freien Lesen wird zuverlässig die Kategorie übersehen, an die man gerade nicht denkt. Und woran man gerade nicht denkt, weiß man nun einmal nicht. Eine Liste, die man abarbeitet, ist deshalb verlässlicher als der beste Vorsatz.

6:40 Fünf Kategorien, und ich gehe sie kurz durch. Fachlich: Randfälle, Fehlerbehandlung, unbemerkt geänderte Regeln. Sicherheit: Sind Eingaben geprüft, wird die Berechtigung an der richtigen Stelle durchgesetzt? Datenschutz: Werden Daten weiter verbreitet als vorher? Schnittstellen: Ändert sich etwas, worauf sich andere verlassen? Und Laufzeit — die klassische Falle: Entsteht ein Aufruf in einer Schleife, der vorher einmal geschah?

7:08 Der Wert dieser Liste liegt nicht in ihrer Vollständigkeit, sondern in ihrer Festigkeit. Eine Liste, die man abarbeitet, schlägt Aufmerksamkeit, die man aufbringen will. Beim Fahrtenbuch möchte ich die dritte Kategorie hervorheben, weil sie hier ungewöhnlich konkret wird. Praktisch jede Fahrt ist ein personenbezogenes Datum — Fahrten sind Bewegungsdaten. Sie sagen, wer wann wo war.

7:31 Eine Auswertung, die es vorher nicht gab, verbreitet diese Information weiter, auch wenn technisch nichts Neues gespeichert wird. Deshalb gehört die Frage in den Review und nicht erst in die Freigabe. Zu diesem Zeitpunkt ist die Änderung noch billig zu ändern; bei der Freigabe steht sie schon.

Tests auf Aussagekraft prüfen

7:49 Zum Diff gehören die Tests — und sie verdienen dieselbe Skepsis wie der Code. Eigentlich sogar mehr, denn sie sind es, die anschließend das Vertrauen tragen sollen. Wenn die Tests nichts taugen, taugt auch die grüne Pipeline nichts, die Sie danach zur Freigabe heranziehen. Denn eine grüne Pipeline ist genau so viel wert wie die Tests, die darin laufen.

8:10 Ein grüner Testlauf sagt für sich genommen nichts über die Güte der Tests aus. Das haben wir in Modul sieben ausführlich gesehen. Und jetzt kommt der Punkt, der vielen zunächst widersinnig erscheint: Ein Diff mit vielen neuen Tests kann die Lage sogar verschlechtern. Nämlich dann, wenn diese Tests sich an Interna klammern. Dann ist jede spätere Änderung teurer, ohne dass die Sicherheit gestiegen wäre.

8:33 Sie haben Kosten eingekauft und keinen Schutz. Vier Fragen, die sich in Sekunden stellen lassen. Welche fachliche Aussage belegt dieser Test? Würde er rot, wenn die Regel falsch umgesetzt wäre? Prüft er das Verhalten oder die Interna? Ist der schwierige Fall dabei oder nur die geraden Wege? Und wenn Sie nach diesen vier Fragen unsicher sind, machen Sie die Probe aus Modul sieben: eine Zeile im Code brechen und sehen, ob überhaupt etwas rot wird.

9:00 Das kostet zwei Minuten und beantwortet die Frage endgültig, statt sie zu diskutieren. Der erste Punkt ist der Zählreflex: Die Zahl neuer Tests wird für ein gutes Zeichen gehalten. Sie ist keins, sie ist erst einmal nur Volumen. Der zweite ist der psychologisch verständliche — Tests weniger skeptisch prüfen als den Code, weil sie ja auf unserer Seite stehen. Genau deshalb gehören sie besonders geprüft.

9:25 Der dritte betrifft die Interna-Falle von eben. Und der vierte ist der Kurzschluss, der die ganze Kette entwertet: aus einem grünen Lauf auf geprüftes Verhalten schließen.

KI als zweite Perspektive

9:36 Jetzt zu einer naheliegenden Frage: Kann man den Review nicht auch von einem Assistenten machen lassen? Die Antwort ist ja, unter drei Bedingungen — und wenn eine davon fehlt, bekommen Sie etwas, das nach Prüfung aussieht und keine ist. Die erste Bedingung ist dabei die interessanteste, weil sie technisch begründet ist. Erstens frischer Kontext: nicht derselbe Lauf, der die Änderung gebaut hat.

9:59 Zweitens eine gezielte Frage — prüfe auf Berechtigungslücken liefert Brauchbares, prüfe auf Qualität liefert eine Liste allgemeiner Hinweise. Und drittens: als Ergänzung, nie als Ersatz. Denn was fachlich nur im Betrieb bekannt ist, steht in keinem Repository. Dass eine Regel bei Kranz und Söhne so gar nicht gilt, weil die Standortleitung das anders handhabt — das weiß kein Modell, und es kann es auch nicht wissen.

10:25 Die erste Bedingung ist keine Vorsichtsmaßnahme, sie hat einen handfesten Grund. Wer denselben Agenten seine eigene Arbeit prüfen lässt, bekommt eine Bestätigung — weil dieselben Annahmen noch im Kontext stehen und die Antwort färben. Und dass das, was im Kontext steht, das Ergebnis messbar beeinflusst, haben wir in Modul sechs gesehen: über achtzehn Modelle hinweg.

10:46 Das ist also kein Misstrauen, sondern eine Eigenschaft der Technik. Und unabhängig davon, wie viele Meinungen Sie einholen: Die Verantwortung für die Freigabe bleibt beim Menschen.

Wann verwerfen besser ist als nachbessern

10:58 Zum letzten fachlichen Kapitel, und es geht um eine Entscheidung, die vielen schwerfällt. Es gibt einen Punkt, an dem das Nachbessern teurer wird als der zweite Anlauf. Und dieser Punkt wird regelmäßig überschritten — nicht aus Unkenntnis, sondern aus einem Mechanismus, der einen Namen hat. Der Mechanismus dahinter ist gut untersucht und wirkt auch dann, wenn man ihn kennt.

11:20 Das Verwerfen fällt schwer, weil bereits Arbeit steckengeblieben ist. Das ist die Sunk-Cost-Falle in Reinform, und sie wirkt auch dann, wenn man sie kennt. Genau dieser Reflex führt in Korrekturrunden, die immer weiter von einem sauberen Ergebnis wegführen. Interessant ist, dass Sandi Metz dieselbe Dynamik für falsche Abstraktionen beschreibt — spätere Bearbeiter halten den Wildwuchs für erhaltenswert, weil so viel Arbeit darin steckt.

11:45 Es ist derselbe Mechanismus, nur auf anderer Ebene. Diese vier Punkte sind eigentlich Warnsignale, keine Fehler — und ich empfehle, sie sich zu merken. Die Änderung beruht auf einem grundlegenden Missverständnis der Aufgabe. Sie ist so groß, dass niemand sie vollständig gelesen hat. Nach jeder Korrekturrunde entstehen neue Probleme an anderer Stelle.

12:06 Oder man ertappt sich beim Gedanken, es selbst schneller zu können. Wenn zwei davon zutreffen, ist die Entscheidung meist schon gefallen — es fehlt nur noch der Mut, sie auszusprechen. Und jetzt der tröstliche Teil, der das Verwerfen erleichtert. Der zweite Anlauf ist meist deutlich besser als der erste — und zwar nicht zufällig.

12:26 Aus dem misslungenen Versuch wissen Sie, was im Auftrag gefehlt hat. Der neue Auftrag ist also schärfer als der alte, und zwar an genau der Stelle, an der es schiefging. Damit ist das Verwerfen kein Verlust. Es ist der Ertrag der ersten Runde. Wer das verinnerlicht hat, entscheidet früher — und dann kostet die Entscheidung auch weniger.

Tagesübung: Ein problematischer Pull Request

12:47 Damit zur Tagesübung, die den zweiten Tag abschließt. Sie bekommen eine umfangreiche generierte Änderung am Fahrtenbuch, die ihren Auftrag scheinbar erfüllt — und genau dieses scheinbar ist der Punkt. Es geht nicht um den offensichtlichen Fehler. Es geht um das, was eine sorgfältige Prüfung findet und ein flüchtiger Blick nicht.

13:06 Enthalten sind mindestens vier Probleme: eine unbemerkte Verhaltensänderung, eine überflüssige Abstraktion, eine Berechtigungslücke und ein Test ohne Aussagekraft. Sie prüfen in Zweiergruppen entlang der fünf Kategorien dieses Moduls und dokumentieren jeden Befund mit Fundstelle und Begründung. Dann kommt die Entscheidung, und die möchte ich ausdrücklich verlangt haben: nachbessern oder verwerfen. Nicht offenlassen.

13:30 Und was Sie entscheiden, setzen Sie um und verifizieren es erneut. Nehmen Sie sich für die Dokumentation der Befunde ausreichend Zeit — sie ist im Plenum die Grundlage des Vergleichs. Fünf Schritte, und der letzte ist der lehrreichste. Im Plenum vergleichen wir, welche Befunde alle Gruppen hatten und welche nur einzelne — und vor allem, woran das lag.

13:51 Meine Erfahrung: Die Befunde, die alle finden, sind die fachlichen. Die Befunde, die nur einzelne finden, sind die aus den Kategorien, die man leicht vergisst — Laufzeit und Datenschutz. Genau deshalb arbeiten wir mit einer festen Liste statt mit Aufmerksamkeit. Das ist die Botschaft dieses Tages.