Qualitätssicherung KI-generierten Codes

Qualitätssicherung KI-generierten Codes

0:00 Dies ist das letzte Fachmodul, und es schließt den Kreis. Wir haben gelernt, wie man Typen baut, wie man Grenzen zieht und wie man Aufgaben delegiert. Jetzt geht es darum, das Ergebnis zu prüfen. Der Leitsatz ist etwas länger als sonst, aber er lohnt sich: Ein verschwundener Compilerfehler kann heißen, dass das Problem behoben wurde — oder dass jemand dem Compiler den Mund verboten hat.

0:22 Und im Änderungssatz sehen beide Fälle nach Fortschritt aus. Diesen Unterschied zu erkennen, ist die Fähigkeit, um die es in den nächsten Minuten geht.

Qualitätssicherung KI-generierten Codes

0:31 Wir gehen acht Prüfrichtungen durch und fassen sie am Ende zu einer Checkliste zusammen. Ein Wort vorweg zu dieser Liste: Sie ist bewusst als Fragenliste formuliert, nicht als Anforderungsliste. Der Unterschied ist wesentlich. Eine Anforderung erzeugt Arbeit, sobald sie dasteht — eine Frage darf mit „hier nicht nötig" beantwortet werden.

0:51 Wer das verwechselt, produziert Über-Engineering und verliert die Mannschaft. Fangen wir mit der ersten und wichtigsten Frage an.

Gelöst oder nur verborgen?

1:00 Die erste Frage bei jedem generierten Änderungssatz lautet: Wurde das Problem gelöst oder nur verborgen? Der Unterschied ist im Code sichtbar — aber nur, wenn man gezielt danach sieht. Denn beides sieht nach Fortschritt aus, und beides macht die Meldung weg. Ein verschwundener Compilerfehler hat zwei mögliche Ursachen. Entweder wurde das zugrunde liegende Problem behoben — oder es wurde eine Konstruktion eingefügt, die den Compiler zum Schweigen bringt.

1:27 Ein Bild aus dem Alltag: Die Warnleuchte im Auto geht aus. Entweder ist der Ölstand jetzt in Ordnung, oder jemand hat die Lampe herausgedreht. In beiden Fällen ist das Armaturenbrett wieder ruhig. Nur eines davon ist eine Reparatur. Und der Unterschied lässt sich nicht am Armaturenbrett ablesen, sondern nur, wenn man nachsieht, was gemacht wurde.

1:48 Der Ausgangsfehler ist einer aus Modul 3: Der Betrag existiert nur in bestimmten Zuständen. Die mittlere Fassung fügt ein Ausrufezeichen ein — eine Behauptung, kein Wissen. Die untere verengt den Zustand und darf danach auf den Betrag zugreifen. Und jetzt kommt der Satz aus der Fußzeile: Beide Fassungen übersetzen. Die erste verlagert den Fehler in den Betrieb, die zweite behandelt ihn. Der Unterschied im Änderungssatz ist ein einziges Zeichen — und im Betriebsverhalten ist er ein Ausfall.

2:19 Deshalb steht dieses Kapitel am Anfang. Der erste Punkt ist der Grundfehler, um den es hier geht: den grünen Übersetzungslauf als Nachweis für eine Lösung nehmen. Grün heißt: Der Compiler hat nichts mehr zu sagen. Es heißt nicht, dass er nichts zu sagen hätte. Der zweite ist ein Lesefehler: nur die geänderten Zeilen ansehen, nicht die eingefügten Konstruktionen — und die sind oft klein und unauffällig.

2:43 Und der dritte ist eine Erwartung, die enttäuscht wird: Nein, ein Werkzeug hat den Unterschied nicht selbst bemerkt. Es hat gemacht, was Sie verlangt haben — der Fehler sollte weg.

Vier Konstruktionen, die still wirken

2:55 Es gibt vier Eingriffe, die Fehlermeldungen zuverlässig beseitigen, ohne irgendetwas zu reparieren. Drei davon stehen im Code. Und der vierte ist der gefährlichste, weil er gar nicht im Code steht, sondern in einer Datei, die im Review oft übersprungen wird. Der abschaltende Typ an einer Signatur. Ein Ausrufezeichen, das Nicht-Leerheit behauptet. Ein Cast auf den gewünschten Typ.

3:18 Und die vierte, die nicht im Code steht: eine abgeschwächte Konfiguration. Eine gelockerte Zeile dort — eine Strenge weniger, eine Lint-Regel deaktiviert — und der ganze übrige Änderungssatz sieht plötzlich harmlos aus. Sie ist die stillste von allen, weil Konfigurationsdateien im Review als Nebensache gelten. Genau deshalb sehen wir sie uns zuerst an.

3:41 Zwei Befehle, wenige Sekunden — und die Reihenfolge ist Absicht. Zuerst die Konfiguration und das Regelwerk: Was hat sich dort geändert? Und dann eine mechanische Suche im übrigen Änderungssatz nach den drei Konstruktionen im Code. Das ersetzt keinen Review, aber es liefert Ihnen in einer halben Minute die Liste der Stellen, die Sie mit besonderer Aufmerksamkeit lesen sollten.

4:03 Ich empfehle Ihnen, sich das als Gewohnheit anzueignen — es ist die billigste Qualitätsmaßnahme in diesem ganzen Seminar. Vier Gründe, und der letzte formuliert es am schärfsten. Die Konfiguration verändert, was der Compiler überhaupt beanstandet. Eine gelockerte Regel lässt allen folgenden Code harmloser aussehen — und zwar zu Recht harmloser, unter den neuen Annahmen.

4:26 Die Änderung selbst ist klein und rutscht in einem großen Änderungssatz leicht durch. Und deshalb: Wer den Code zuerst liest, liest ihn unter aufgehobenen Annahmen. Sie prüfen dann sorgfältig und mit dem falschen Maßstab, was besonders ärgerlich ist.

Typ und Wirklichkeit

4:42 Jetzt die Frage aus Modul 4 und Modul 6, im Review-Kontext. Ein generierter Typ beschreibt oft die Beispiele aus dem Prompt — nicht die Schnittstelle, die er beschreiben soll. Und diesen Unterschied sieht man dem Typ nicht an. Ein generierter Typ beschreibt häufig die Beispieldaten, mit denen er entstanden ist, und nicht die Schnittstelle, die er beschreiben soll.

5:03 Das ist der Befund aus Modul 4, und er kommt hier wieder, weil er im Review überprüfbar ist. Ohne Laufzeitprüfung bleibt das unentdeckt — bis der erste Datensatz eintrifft, der dem Beispiel nicht entspricht. Und das ist selten am ersten Tag. Es ist meistens dann, wenn niemand mehr an diese Änderung denkt, und dann sucht man den Fehler an einer ganz anderen Stelle.

5:24 Vier Prüffragen. Gibt es überhaupt eine Prüfung an der Stelle, an der Daten eintreffen? Stammt der Typ aus der Schnittstellenbeschreibung oder aus Beispielen — das lässt sich oft im Verlauf nachsehen. Sind Felder als verpflichtend markiert, die fachlich fehlen dürfen? Das ist der Streckenware-Fall aus Modul 4. Und die vierte ist die eleganteste: Wird ein geprüfter Wert von einem ungeprüften unterscheidbar geführt?

5:49 Wenn Sie die Marken aus Modul 5 verwenden, können Sie das im Typ sehen — sonst müssen Sie es glauben. Der erste Punkt beschreibt eine sehr menschliche Fehlleistung: die Prüfung im Änderungssatz suchen, sie nicht finden — und ihr Fehlen für Absicht halten. „Wird schon woanders geprüft." Fragen Sie nach, wo. Der zweite ist der klassische Zirkelschluss: einen generierten Typ übernehmen, weil er zu den Testdaten passt, obwohl er aus denselben Testdaten entstanden ist.

6:16 Und der dritte ist der Sonderweg aus Modul 6, den es nicht gibt: Ein Schema in der Antwort macht die Validierung nicht entbehrlich.

Fehlerfälle und Übergänge

6:24 Jetzt eine Beobachtung, die Ihre Lesezeit sinnvoll umverteilt. Der Erfolgspfad gelingt fast immer — und genau deshalb wird er im Review am gründlichsten gelesen, weil er am leichtesten zu lesen ist. Er ist aber die uninteressanteste Stelle des ganzen Änderungssatzes. Generierter Code erledigt den Erfolgspfad zuverlässig. Das ist eine echte Stärke, und man sollte sie anerkennen.

6:48 Geprüft gehört deshalb der Rest: leere Ergebnisse, Zeitüberschreitungen, Abbrüche, gleichzeitige Zugriffe. Und bei Zustandsmodellen die Übergänge, die es fachlich nicht geben darf — der Auftrag, der aus dem abgeholten Zustand zurückspringt. Verteilen Sie Ihre Aufmerksamkeit entsprechend: Überfliegen Sie den Erfolgspfad, lesen Sie die Ränder. Dort entstehen die Ausfälle.

7:11 Fünf Zeilen mit einem klaren Gefälle. Beim Erfolgspfad steht „ja, zuverlässig" — nichts zu tun. Beim leeren Ergebnis „oft nicht". Bei der Zeitüberschreitung „selten". Und bei den beiden unteren — verbotener Übergang und gleichzeitiger Zugriff — steht zweimal „fast nie". Das sind gleichzeitig die beiden, deren Fehlen am teuersten wird.

7:33 Die rechte Spalte sagt Ihnen, woran es im Änderungssatz auffällt: kein Zweig für die leere Liste, kein Abbruch, keine Prüfung, keine Sperre. Sie suchen also nach Abwesenheit — und das ist die schwierigste Art zu lesen. Erinnern Sie sich an die Frage aus Modul 3? Welcher unmögliche Zustand bleibt darstellbar? Sie ist hier die schärfste Waffe, und dazu kommen drei konkrete Nachfragen.

7:58 Bricht der Übersetzungslauf noch, wenn ein Zustand hinzukommt? Ist die Vollständigkeitsprüfung mit dem leeren Typ noch vorhanden — oder still entfallen, weil sie im Weg stand? Und die vierte ist die häufigste Verschlechterung überhaupt: Wurde ein Zustandstyp zu einem Objekt mit optionalen Feldern verflacht? Das passiert oft, weil es kurzfristig alles einfacher macht.

Öffentliche API und Abhängigkeiten

8:21 Zwei Dinge, die nebenbei passieren und die man nur findet, wenn man gezielt danach sieht: eine geänderte öffentliche Signatur und eine neu hinzugekommene Bibliothek. Beide sind keine Umsetzung, sondern eine Entscheidung. Eine kleine Aufgabe darf keine öffentliche Signatur verändern und keine neue Bibliothek mitbringen. Beides geschieht trotzdem regelmäßig nebenbei — und beides fällt im Änderungssatz nur auf, wenn man gezielt danach sieht.

8:47 Der Grund ist bemerkenswert: Bei der Signatur, weil sie funktioniert; die Tests laufen ja, das Repository ist in sich stimmig. Und bei der Abhängigkeit, weil sie das Problem tatsächlich löst. Beides sieht also nach guter Arbeit aus. Es ist nur nicht die beauftragte. Vier Gründe. Eine geänderte Signatur bricht Konsumenten, die gar nicht in Ihrem Repository liegen — deshalb sind die Tests grün.

9:11 Eine neue Abhängigkeit bringt Wartung, Angriffsfläche und Lizenzfragen mit, und keine davon zeigt sich heute. Der dritte Punkt ist die Einordnung: Beides ist eine Entscheidung, keine Umsetzung — und gehört besprochen. Und der vierte schlägt den Bogen zu Modul 12: Beides steht in den Sperrregeln, wenn sie denn geschrieben wurden. Falls nicht, haben Sie jetzt einen guten Anlass.

9:34 Der erste Punkt ist ein reiner Aufmerksamkeitsfehler mit einfacher Abhilfe: nur den Quelltext prüfen und die Manifestdateien überspringen. Nehmen Sie sie in Ihre Standardsuche auf. Der zweite ist eine Denkgewohnheit: eine Abhängigkeit akzeptieren, weil sie das Problem löst — ohne zu fragen, ob es Alternativen gab, etwa dreißig Zeilen eigenen Code.

9:55 Und der dritte ist der Fall aus Modul 1 und 7: interne Typen, die versehentlich Teil einer öffentlichen Signatur werden. Danach sind sie eine Zusage.

Tests, die etwas prüfen

10:04 Jetzt zu den Tests — und ich gebe Ihnen eine einzige Kontrollfrage mit, die sich auf jeden Test anwenden lässt: Welche denkbare Fehlfunktion würde dieser Test bemerken? Sie entlarvt genau die Tests, die aus dem Code abgeleitet wurden statt aus der Fachlichkeit. Ein Test, der die Implementierung nachbaut, prüft nichts — er bestätigt nur, dass der Code tut, was der Code tut. Das ist ein Zirkelschluss mit grünem Balken.

10:29 Erkennbar ist er an der Kontrollfrage: Welche denkbare Fehlfunktion würde dieser Test bemerken? Lautet die Antwort „keine", ist der Test Ballast. Und Ballast ist er nicht nur, weil er nichts prüft — er ist schädlich, weil er Sicherheit vortäuscht und weil ihn beim nächsten Umbau jemand mitpflegen muss. Zwei Zeilen, und der Unterschied ist auf den ersten Blick unscheinbar.

10:52 Die obere rechnet dieselbe Formel noch einmal — wenn der Rabattsatz falsch ist, ist er in beiden Zeilen falsch, und der Test bleibt grün. Die untere nennt das erwartete Ergebnis als Zahl: neuntausend. Diese Zahl kommt aus der Fachlichkeit, nicht aus dem Code — und deshalb kann sie widersprechen. Genau darin liegt der ganze Wert eines Tests: dass er widersprechen kann. Ein Test, der nie widersprechen könnte, ist keiner.

11:18 Der erste Punkt betrifft eine beliebte Kennzahl: Der Abdeckungsgrad misst Ausführung, nicht Prüfung. Ein Test ohne einzige Zusicherung erzeugt hundert Prozent Abdeckung für die durchlaufenen Zeilen — und prüft nichts. Der zweite ist der Befund aus Kapitel 4: Tests akzeptieren, die nur den Erfolgspfad abdecken. Und der dritte ruft Modul 8 in Erinnerung: Testdaten ohne Typ übernehmen.

11:41 Sie bleiben nach einem Modellumbau still falsch und geben grünes Licht für ein Modell, das es nicht mehr gibt.

Security Review

11:48 Jetzt ein Kapitel, das es vor wenigen Jahren so nicht gab. Bei agentisch erzeugtem Code kommt ein Kanal hinzu, den klassische Reviews nicht kennen. Der Satz dazu lautet: Was im Repository steht, ist Eingabe. Und dazu gibt es einen belegten Fall, der eindrucksvoller ist als jede Statistik. Die klassischen Regeln gelten weiter: Alles, was hereinkommt, ist zu prüfen; alles, was hinausgeht, auf ungewollte Preisgabe. Neu ist der dritte Kanal — Texte im Repository selbst.

12:18 Kommentare, README-Dateien, Konfigurationen, Beschreibungen von Pull Requests sind für einen Agenten Eingabe und können Anweisungen enthalten. Das ist ein Perspektivwechsel, an den man sich gewöhnen muss: Ein Kommentar ist für einen Menschen Erläuterung. Für einen Agenten ist er Text, den er liest und der ihn beeinflusst.

12:37 Und Kommentare schreibt in vielen Projekten jeder. Ein dokumentierter Fall mit Kennung, Einstufung und Behebung — nachlesbar, nicht ausgedacht. Die Zeile, auf die es ankommt, ist die vierte: Die Konfiguration wurde so geändert, dass Aktionen nicht mehr bestätigt werden müssen. Lassen Sie das kurz wirken. Das Werkzeug hat seine eigene Berechtigungseinstellung verändert — über eine Anweisung, die in einer Datei des Arbeitsbereichs eingebettet war.

13:04 Ein Hinweis zur Sorgfalt in der Fußzeile: Sekundärquellen nennen eine höhere Schwere als der Hersteller. Wir nennen den Herstellerwert und weisen die Abweichung aus. Vier Folgerungen, und die dritte schlägt den Bogen zu Modul 12. Fremde Inhalte im Repository sind nicht vertrauenswürdiger als eine Netzantwort — das ist dieselbe Grenze wie in Modul 6, nur an einer unerwarteten Stelle.

13:27 Berechtigungsdateien gehören in den Änderungssatz-Review wie Quelltext. Und dann: Eine Bitte in einer Anweisungsdatei hätte diesen Fall nicht verhindert — genau deshalb haben wir über die verbindliche Ebene gesprochen. Und viertens: Generierter Code durchläuft dieselbe Sicherheitsprüfung wie fremder Code.

Die Review-Checkliste

13:46 Fassen wir zusammen. Neun Fragen an einen generierten Pull Request. Und ich betone es noch einmal, weil es über die Brauchbarkeit entscheidet: Es sind Fragen, keine Anforderungen. Eine Anforderung erzeugt Arbeit, sobald sie dasteht. Eine Frage darf mit „hier nicht nötig" beantwortet werden. Neun Zeilen, und die Reihenfolge ist nicht zufällig: Die Konfiguration steht oben, weil sie alles andere relativiert. Dann die stillen Konstruktionen.

14:15 Dann die Prüfung an der Datengrenze, die Zustandsmodelle und die Vollständigkeitsprüfung. Danach öffentliche Signaturen und neue Abhängigkeiten. Dann die Testfrage. Und ganz unten die neue: Wurden Berechtigungen oder Hooks berührt? Die Fußzeile nennt den Zweck, und der ist bescheiden: nicht Bürokratie, sondern dass unter Zeitdruck niemand die immer gleichen Punkte übersieht.

14:38 Genau unter Zeitdruck übersieht man sie nämlich. Der erste Punkt kennen wir aus Modul 11 und er gilt hier genauso: nicht jeden Befund abarbeiten. Wer beauftragt ist, Lücken zu finden, findet welche — Sie entscheiden, welche zählen. Der zweite ist die Warnung, mit der dieses Kapitel begonnen hat: die Liste zur Anforderung machen und damit Über-Engineering erzeugen.

14:59 Und der dritte ist ein methodischer Hinweis: Lassen Sie nicht dieselbe Sitzung prüfen, die den Code geschrieben hat. Sie bringt ihre eigenen Annahmen mit und prüft sie gegen sich selbst — dasselbe Problem wie beim Test von eben.

Übung — einen Pull Request prüfen

15:13 Jetzt prüfen Sie selbst — einen umfangreichen generierten Pull Request mit sechs eingebauten Schwächen. Und achten Sie auf die Tagline, denn dort steht das eigentliche Bewertungskriterium: Befunde als überprüfbare Änderungswünsche, nicht als Meinung. Das Lernziel: einen umfangreichen generierten Änderungssatz systematisch prüfen und Befunde so formulieren, dass ihre Behebung überprüfbar ist.

15:36 Erfolgreich sind Sie, wenn die eingebauten Schwächen gefunden, nach Wirkung priorisiert und als überprüfbare Änderungswünsche formuliert sind — nicht als Stilhinweise. Und eine der sechs Schwächen ist eine gelockerte Zeile in der Konfiguration; sie entscheidet über alle anderen. Wer früh fertig ist, benennt einen Befund, den er bewusst nicht behebt, und begründet, warum die Behebung den Code verschlechtern würde.

15:59 Diese Übung ist mindestens so wertvoll wie das Finden. Fünf Schritte in der Reihenfolge, die wir hergeleitet haben: Konfiguration und Manifestdateien zuerst, noch vor dem Code. Dann die mechanische Suche nach den stillen Konstruktionen. Dann die neun Fragen der Reihe nach. Danach priorisieren Sie nach Wirkung, nicht nach Fundreihenfolge — das ist wichtiger, als es klingt, weil sonst der erste Fund die Diskussion bestimmt.

16:24 Und im letzten Schritt formulieren Sie je Befund einen überprüfbaren Änderungswunsch. Denn ein Befund ohne prüfbaren Wunsch ist eine Meinung — und wird im Zweifel überstimmt. Vier Sätze zum Mitnehmen. Ein verschwundener Fehler kann behoben oder zum Schweigen gebracht worden sein — das ist die erste Frage bei jedem Änderungssatz.

16:45 Die Konfiguration prüfen Sie zuerst, denn sie hebt die Aussagekraft aller anderen Prüfungen auf. Texte im Repository sind für einen Agenten Eingabe, nicht Dokumentation. Und die Checkliste stellt Fragen; wer sie zur Anforderung macht, erzeugt Über-Engineering. Im letzten Modul bringen Sie alles aus drei Tagen in einem Abschlussprojekt zusammen.