Qualität nicht an den Agenten delegieren

Qualität nicht an den Agenten delegieren

0:00 Plausibel und belegt sind zwei verschiedene Dinge — und generierter Code ist zuverlässig das erste. Das ist keine Kritik an der Technik, sondern eine Beschreibung ihrer Funktionsweise: Ein Sprachmodell erzeugt, was wahrscheinlich richtig aussieht. Das deckt sich oft mit dem, was richtig ist, und manchmal eben nicht. Der Unterschied ist von außen nicht zu sehen.

0:21 Deshalb ändert sich beim Einsatz von Agenten nicht der Qualitätsmaßstab, sondern nur die Frage, wo man hinschaut.

Qualität nicht an den Agenten delegieren

0:28 Vier Themen: der Unterschied zwischen Plausibilität und Nachweis, die Testarten und was sie belegen, die statische Prüfung und zum Schluss das Diff-Review mit Blick auf die stillen Änderungen. Das letzte Thema ist das, bei dem die Übung wehtut — wir arbeiten mit einer Änderung, die vollständig durch die Pipeline läuft und trotzdem zwei Fehler enthält.

Plausible Ausgabe und belastbarer Nachweis

0:47 Fangen wir mit dem Maßstab an. Und der ist erfreulich eindeutig, weil ihn jemand für uns formuliert hat. NIST hält in seiner Leitlinie zur Entwicklung mit generativer KI ausdrücklich fest, dass zwischen menschlich geschriebenem und KI-generiertem Quellcode nicht unterschieden wird. Die Begründung ist bemerkenswert schlicht: weil ohnehin jeder Quellcode vor seiner Verwendung auf Schwachstellen und andere Probleme geprüft werden soll.

1:12 Das ist eine Einladung, die Diskussion abzukürzen. Es braucht keine Sonderregeln für KI-Code — es braucht die Regeln, die Sie ohnehin haben sollten. Die linke Spalte sammelt, was sich gut anfühlt: Der Code liest sich richtig, der Agent erklärt sein Vorgehen, die Pipeline ist grün, es gab keine Rückfragen. Die rechte Spalte sammelt, was etwas beweist. Der Unterschied zwischen beiden Spalten ist die Frage, ob es einen Fall gibt, in dem die Aussage falsch wäre.

1:40 Ein Test, der bei falschem Code fehlschlägt, beweist etwas. Ein Code, der sich richtig liest, beweist nichts — dafür ist Lesen zu schwach. Der erste Punkt ist der grundsätzliche: Derselbe Kontext, der den Fehler erzeugt hat, prüft ihn. Wenn ein Modell eine falsche Annahme getroffen hat, wird es diese Annahme beim Prüfen wieder treffen — sie steht ja im Kontext.

2:02 Der zweite Punkt ist die praktische Ausprägung davon: Ein generierter Test spiegelt oft die generierte Implementierung. Er ist grün, und zwar genau dann, wenn der Code das tut, was er tut — nicht, wenn er das tut, was er soll. Der erste Punkt ist die Abkürzung, die im Alltag am meisten kostet: Die Zusammenfassung des Agenten ersetzt das Lesen des Diffs.

2:23 Die Zusammenfassung ist gut geschrieben, vollständig klingend und beschreibt die Absicht — nicht zwangsläufig das Ergebnis. Der zweite ist der, gegen den man organisatorisch angehen muss: Der Agent schreibt Implementierung und Test in einem Zug. Wenn das unvermeidbar ist, muss wenigstens das Testorakel von außen kommen.

Testarten und ihre Aussagekraft

2:42 Kommen wir zu den Tests selbst. Die Arten kennen Sie — interessant ist, was sie jeweils nicht abdecken. Vier Arten, vier Aussagen: Unit-Tests belegen einzelne Einheiten, Integrationstests das Zusammenspiel, Contract-Tests die Einhaltung einer Schnittstellenzusage, Regressionstests den Erhalt bisherigen Verhaltens. Für einen Agentenauftrag kommt eine fünfte Frage dazu, und sie ist die wichtigste: Treffen sie die Akzeptanzkriterien aus der Spezifikation?

3:10 Ein vollständiger Testkatalog, der an den Kriterien vorbeiprüft, belegt Fleiß und nicht Erfüllung. Lesen Sie vor allem die rechte Spalte — die blinden Flecken. Der Unit-Test prüft die Regel, sagt aber nichts über den Aufruf im echten Ablauf. Der Integrationstest deckt Formular und Server ab, aber nicht das Verhalten des Kontenwerks. Der Contract-Test prüft die Zusage, nicht die fachliche Richtigkeit.

3:35 Und die vierte Zeile ist die, auf die ich hinauswill: Der Regressionstest deckt genau das Nicht-Ziel aus unserer Spezifikation ab — der Altbestand bleibt unberührt. So werden Nicht-Ziele prüfbar. Der erste Satz ist der entscheidende: Der Erfolgsfall gelingt fast immer, auch mit falscher Logik. Eine Prüfung, die versehentlich immer wahr liefert, besteht jeden positiven Test.

3:58 Erst die Ablehnung zeigt, ob die Bedingung überhaupt greift. Deshalb sind Negativtests bei generiertem Code nicht das Sahnehäubchen, sondern der eigentliche Nachweis — und es sind die, die ein Agent von sich aus am seltensten schreibt. Der erste Punkt ist die Kernaussage des Kapitels in einem Satz: Der Test prüft, was der Code tut, nicht was er tun soll.

4:19 Der dritte ist eine sehr konkrete Falle in unserem Beispiel: Ein Mock bildet das Kontenwerk nur im Erfolgsfall ab. Dann ist der Ausfall nie getestet, obwohl er in der Spezifikation als Kriterium steht. Und der vierte ist eine einfache Probe, die Sie in jedem Review machen können: Tauchen die Akzeptanzkriterien in irgendeinem Testnamen auf?

Statische Prüfung des Ergebnisses

4:39 Kommen wir zu den Prüfungen, die nichts kosten und über die niemand diskutieren muss. Statische Prüfungen bewerten den Code, ohne ihn auszuführen: Linting für Stil und bekannte Fehlermuster, Typprüfung für Vertragsverletzungen, statische Analyse für Sicherheitsmuster, dazu Scans für Abhängigkeiten und Geheimnisse. Sie sind schnell, deterministisch und nicht verhandelbar — und genau deshalb die idealen Schranken für generierten Code.

5:04 Anders als ein Review ermüden sie nicht, und anders als ein Mensch lassen sie sich nicht von einer guten Begründung überzeugen. Die Reihenfolge ist nicht beliebig. Die Typprüfung zuerst, weil sie am schnellsten und eindeutigsten bricht — es hat keinen Sinn, eine Sicherheitsanalyse über Code laufen zu lassen, der nicht übersetzt.

5:23 Dann Linting, dann statische Analyse. Und zum Schluss die beiden, die bei generiertem Code am häufigsten anschlagen: der Scan der Abhängigkeiten und der Scan nach Geheimnissen. Diese Reihenfolge spart Wartezeit bei jedem Lauf. Hier ist ein Verhalten, das man kennen sollte: Ein Agent löst Probleme gern durch ein zusätzliches Paket.

5:44 Das ist aus seiner Sicht vernünftig — es gibt eine Bibliothek dafür, also nimmt er sie. Was er nicht prüft, sind Herkunft, Pflegezustand und Lizenz. Und der dritte Punkt ist der, der die Sache ernst macht: Jede neue Abhängigkeit vergrößert die Angriffsfläche dauerhaft. Deshalb gehört die Entscheidung für ein Paket ins Review — als bewusste Entscheidung, nicht als Nebenwirkung.

6:07 Der erste Punkt ist die verbreitetste Wirkungslosigkeit: Die Analyse läuft, aber neue Funde blockieren nichts. Dann ist sie ein Bericht, den niemand liest. Der zweite ist der, gegen den man technisch vorgehen muss: Der Agent darf Regeln unterdrücken, um die Pipeline grün zu bekommen. Das ist für ihn der kürzeste Weg zum Ziel, und er wird ihn nehmen. Und der vierte ist ein Detail mit Folgen: Abhängigkeiten werden geprüft, transitive nicht.

Diff-Review mit Blick auf Nebenwirkungen

6:34 Bleibt das Review. Und dabei vor allem der Blick auf das, was neben der beauftragten Änderung passiert ist. Das Diff-Review liest die tatsächliche Änderung — nicht die Beschreibung des Agenten. Der Fokus liegt dabei auf dem, was nicht beauftragt war: angepasste Tests, gelockerte Prüfungen, geänderte Konfiguration, entfernte Sonderfälle.

6:55 Das sind die Stellen, an denen ein Agent Widerstände auflöst, die ihn aufgehalten haben. Aus seiner Sicht hat er ein Hindernis beseitigt. Aus Ihrer Sicht war das Hindernis eine Zusicherung. Vier Stellen mit je einer Frage. Bestehende Tests: Wurde eine Erwartung abgeschwächt? Konfiguration: Wurde eine Schranke stillschweigend gesetzt?

7:16 Fehlerbehandlung: Wird ein Fehler jetzt verschluckt? Nicht-Ziele: Wurde etwas berührt, was unberührt bleiben sollte? Die Fußzeile sagt, warum diese vier: Alle sind im Diff sichtbar — und in der Zusammenfassung des Agenten üblicherweise nicht, weil sie aus seiner Sicht Nebensache waren. Genau genommen sind es vier. Gegen die Spezifikation: Ist jedes Kriterium abgedeckt? Gegen den Plan: Wurde abgewichen, und warum?

7:43 Gegen die Nicht-Ziele: Wurde die Grenze eingehalten? Und gegen den Bestand: Passt der Code zum umgebenden Stil? Das klingt nach viel und ist es nicht — wenn Spezifikation und Plan vorliegen, dauert es Minuten. Wenn sie nicht vorliegen, bleibt nur der vierte Maßstab, und der ist der schwächste. Der erste Punkt ist menschlich und deshalb schwer abzustellen: Große Diffs werden überflogen, weil sie groß sind. Dagegen hilft nur der Schnitt aus Modul 11.

8:12 Der zweite ist der, auf den es in diesem Modul ankommt: Änderungen an Tests werden als Nebensache durchgewunken. Der dritte ist ein Organisationsfehler: Der Reviewer ist derselbe, der den Auftrag formuliert hat — der prüft dann seine eigene Erwartung. Und der vierte macht die Sache im Zweifel wertlos: Das Review findet statt, hinterlässt aber keine Spur.

Übung

8:34 Jetzt wird es konkret. Wir arbeiten mit einer Änderung, die alles besteht — und trotzdem falsch ist. Die vorbereitete Agentenänderung läuft vollständig durch die Pipeline. Die neue Validierung greift sogar korrekt. Und trotzdem enthält sie zwei Fehler, beide außerhalb der beauftragten Stelle. Genau das ist der Fall, für den dieses Modul existiert: Wenn die offensichtlichen Prüfungen bestehen, muss man wissen, wo man sonst hinschaut.

9:01 Finden Sie beide Fehler, benennen Sie für jeden die fehlende oder unwirksame Schranke, und schreiben Sie für einen davon einen Test, der ihn künftig aufdeckt. Der Hinweis auf der Folie verrät bereits die Richtung: Ein bestehender Test wurde abgeschwächt, und eine Prüfung auf leere Beträge wurde entfernt. Die eigentliche Frage ist nicht, ob Sie das finden — sondern welche Schranke es hätte verhindern müssen.

9:24 Der erste Punkt ist der, an dem die meisten hängenbleiben: Gesucht wird in der geänderten Datei, die Fehler liegen daneben. Der zweite ist der interessanteste — der abgeschwächte Test wird gefunden, aber als Verbesserung gelesen. Er sieht ja aufgeräumter aus. Der dritte ist ein handwerklicher Hinweis für den neuen Test: Prüfen Sie die verlorene Zusicherung, nicht den konkreten Fehler.

9:46 Im nächsten Modul geht es darum, diese Prüfungen so zu verankern, dass sie niemand umgehen kann.