Quality Gates, Reproduzierbarkeit und Kennzahlen

Quality Gates, Reproduzierbarkeit und Kennzahlen

0:00 Was man nicht wiederholen kann, kann man nicht verbessern. Und was man falsch misst, verschlimmert man aktiv. Beides trifft auf den Einsatz von Coding Agents besonders zu, weil hier zwei verbreitete Kennzahlen — erzeugte Codemenge und Testabdeckung — nicht nur wenig aussagen, sondern sich vom Agenten auch noch mühelos optimieren lassen.

0:19 Dieses Modul schließt Tag zwei ab mit der Frage: Woran erkennen Sie eigentlich, ob sich das lohnt?

Quality Gates, Reproduzierbarkeit und Kennzahlen

0:25 Vier Themen, die zusammengehören. Erst die Schranken, die eine Änderung tatsächlich aufhalten. Dann die Frage, was ein Lauf festhalten muss, damit man ihn vergleichen kann. Dann die Telemetrie und ihre Datenschutzseite. Und zum Schluss die Kennzahlen, die etwas über den Nutzen sagen — im Unterschied zu denen, die nur über den Umfang sprechen.

Qualitätsschranken in CI/CD

0:46 Fangen wir mit den Schranken an. Der entscheidende Punkt ist nicht ihr Inhalt, sondern ihr Ort. Eine Qualitätsschranke hält eine Änderung auf, bis sie besteht. Und damit das funktioniert, muss dreierlei gelten: Sie läuft in der Pipeline, sie läuft unter anderen Rechten als der Agent, und sie lässt sich nicht aus dem Auftrag heraus abschalten.

1:06 Der letzte Punkt ist der, der in der Praxis fehlt. Wenn der Agent die Pipelinekonfiguration ändern darf, ist die Schranke eine Bitte — und wir hatten in Modul 1 schon geklärt, was Bitten wert sind. Zwei Spalten, und die Trennlinie verläuft genau an der richtigen Stelle. Der Agent darf Code im Zweig ändern, Tests hinzufügen, einen Merge vorschlagen und die Pipeline auslösen.

1:28 Was er nicht darf: Prüfungen definieren, den Merge freigeben, Regeln durchsetzen, Schranken abschalten. Das ist dieselbe Aufgabenteilung wie zwischen einem Entwickler und der Freigabestelle — nur dass sie hier technisch erzwungen werden muss und nicht über Vertrauen läuft. Vier Prüfungen als Mindestmaß. Tests einschließlich der Akzeptanzkriterien aus der Spezifikation — das ist die Verbindung zu Modul 10.

1:52 Typprüfung und statische Analyse ohne neue Funde. Der Scan nach Geheimnissen über den gesamten Zweig, nicht nur über den letzten Commit. Und ein gegengezeichnetes Diff-Review von zweiter Hand. Nur die letzte dieser vier kostet Menschenzeit — die anderen drei kosten einmal Einrichtung und danach nichts mehr. Der zweite Punkt ist die Schleichvariante des Scheiterns: Eine rote Prüfung wird als bekannt markiert und bleibt es.

2:17 Nach einem halben Jahr sind drei Prüfungen dauerhaft bekannt, und die Pipeline ist grün, weil sie nichts mehr prüft. Der vierte ist der, der unter Termindruck kommt und den man vorher entscheiden sollte: Für Agentenänderungen gilt eine Ausnahme, weil es sonst zu lange dauert. Damit ist der ganze Aufbau hinfällig.

Reproduzierbare Agentenläufe

2:36 Kommen wir zu einer Frage, die im Alltag erstaunlich selten gestellt wird: Was genau ist eigentlich passiert? Ein Lauf ist reproduzierbar, wenn Auftrag, bereitgestellter Kontext, verfügbarer Werkzeugsatz und die Folge der Aufrufe festgehalten sind. Wichtig ist, was das nicht bedeutet: Das Ergebnis wird dadurch nicht identisch. Modellentscheidungen bleiben probabilistisch, das haben wir in Modul 1 geklärt.

3:00 Was reproduzierbar wird, ist die Erklärbarkeit — der Unterschied zwischen zwei Läufen lässt sich zurückführen auf etwas, das sich geändert hat. Vier Angaben, und die Fußzeile hebt die zweite hervor: Ohne den Werkzeugsatz ist jeder Vergleich wertlos. Ein zusätzliches Werkzeug ändert das Verhalten eines Agenten vollständig — er nimmt einen anderen Weg, weil ihm ein anderer Weg offen steht.

3:23 Wer zwei Läufe vergleicht und nicht weiß, welche Werkzeuge jeweils zur Verfügung standen, vergleicht zwei verschiedene Systeme und zieht Schlüsse über das Modell. Vier Beobachtungen, und jede ist ein Hinweis auf eine andere Ursache. Große Streuung bei gleichem Auftrag deutet auf eine unscharfe Spezifikation. Unterschiedliche Werkzeugwahl deutet auf unklare Beschreibungen — das ist der Rückkanal zu Modul 7. Wiederkehrende Sackgassen deuten auf fehlenden Kontext, also zurück zu Modul 9.

3:52 Und gleiche Wege bei gleichem Auftrag sind ein gutes Zeichen. Das ist ein überraschend brauchbares Diagnosewerkzeug für die eigene Arbeitsweise. Der erste Punkt ist der verbreitetste: Protokolliert wird das Ergebnis, nicht der Weg dorthin. Damit ist genau die Information weg, die man für die Diagnose bräuchte. Der dritte ist ein Begriffsfehler mit Folgen: Reproduzierbarkeit wird mit Determinismus verwechselt, und dann enttäuscht man sich selbst.

4:18 Und der vierte ist ein Souveränitätsthema, über das man einmal nachdenken sollte: Die Protokolle liegen im Werkzeug des Anbieters und nicht im Repository.

Telemetrie ohne Datenpreisgabe

4:28 Jetzt zu der Frage, wie man ausreichend protokolliert, ohne einen Datenschutzvorfall zu erzeugen. Telemetrie erfasst, was passiert ist — nicht, was gesagt wurde. Und MCP macht es einem dabei leicht: In den Metadaten sind die Schlüssel für den Trace-Kontext nach W3C reserviert, ausdrücklich als Ausnahme von den eigenen Namensregeln.

4:49 Der Grund steht in der Spezifikation: Kompatibilität zu den OpenTelemetry-Konventionen. Ein Werkzeugaufruf fügt sich damit ohne Zusatzarbeit in eine bestehende Trace-Kette ein — über Systemgrenzen hinweg. Fünf Schritte, und der zweite ist der wirksamste: Bezeichner statt Inhalte. Die Nummer der Serviceanfrage statt ihres Freitexts.

5:10 Damit lässt sich alles nachvollziehen, was für die Diagnose zählt, und nichts steht im Protokoll, was dort nicht hingehört. Der fünfte Schritt ist derselbe wie in Modul 9 und aus demselben Grund wichtig: Die Redaktion testen, nicht nur konfigurieren. Eine Filterregel mit Tippfehler sieht aus wie eine Filterregel. Vier Gründe, und drei davon sind Risiken. Prompts enthalten regelmäßig Inhalte aus fremden Quellen. Sie können personenbezogene Daten tragen.

5:37 Sie sind lang und machen die Auswertung teuer. Und der vierte ist der, der die Entscheidung leichtmacht: Der Erkenntniswert liegt ohnehin in der Aufruffolge, nicht im Wortlaut. Sie verlieren also fast nichts und vermeiden eine ganze Klasse von Problemen. Der erste Punkt ist die Geschichte jedes Protokollierungsvorfalls: Zur Fehlersuche wird alles mitgeschrieben und nie wieder abgeschaltet.

6:01 Der zweite ist ein Architekturfehler mit rechtlichen Folgen: Die Redaktion läuft im Auswertungswerkzeug statt beim Schreiben. Dann liegen die Rohdaten trotzdem irgendwo. Und der dritte ist eine Beobachtung aus vielen Projekten: Protokolle sind für alle lesbar, weil sie technisch wirken — und niemand hat je einen Zugriffsschutz dafür vorgesehen.

Kennzahlen, die etwas aussagen

6:20 Zum Abschluss die Frage, die am Ende jede Geschäftsführung stellt — und für die man besser eine gute Antwort hat. Drei Kennzahlen reichen. Erfolgsquote je Auftragsart. Anzahl der Korrekturschleifen bis zur Abnahme. Kosten und Laufzeit je abgeschlossenem Auftrag. Zusammen sagen sie, wo sich die Delegation lohnt und wo nicht — und das ist die einzige Frage, die wirklich interessiert.

6:44 Beachten Sie das „je Auftragsart": Der Gesamtdurchschnitt ist die unbrauchbarste aller Zahlen, weil er gute und schlechte Fälle zu einem mittelmäßigen Ergebnis verrührt. Die rechte Spalte ist das Eigentliche: Was bedeutet ein schlechter Wert? Niedrige Erfolgsquote bei einer Auftragsart heißt, dass sich diese Art nicht zur Delegation eignet — das ist eine brauchbare Erkenntnis und kein Misserfolg.

7:08 Viele Korrekturschleifen heißen, dass Spezifikation oder Kontext unscharf sind. Hohe Kosten deuten auf einen zu großen Zuschnitt. Und lange Laufzeit bis zur Abnahme zeigt meist, dass der Engpass beim prüfenden Menschen liegt — nicht beim Agenten. Zeilen und Token messen Aufwand, nicht Nutzen. Testabdeckung steigt auch durch Tests, die nichts prüfen — und wir haben in Modul 12 gesehen, wie leicht solche Tests entstehen.

7:34 Der dritte Punkt ist der entscheidende: Beide lassen sich vom Agenten mühelos optimieren. Sobald eine Zahl zum Ziel wird, optimiert das System sie — und zwar direkt, nicht über den Umweg der eigentlichen Absicht. Das ist ein alter Befund, und er gilt hier besonders. Der erste Punkt ist eine Definitionsfrage mit großer Wirkung: Erfolg wird als Pipeline grün definiert statt als Abnahme erfolgt.

7:58 Der zweite ist der Normalzustand vieler Kennzahlensysteme: erhoben, aber nie mit einer Entscheidung verbunden. Der dritte ist ein Vergleichsfehler — man misst gegen Handarbeit, ohne den Auftragszuschnitt gleich zu halten. Und der vierte ist die Wiederholung des Kernpunkts: Die Zahlen werden zum Ziel und verlieren ihre Aussage.

Übung

8:17 Zum Abschluss von Tag zwei: Schranken setzen und dann tatsächlich hinsehen, was die Läufe erzählen. Zwei Teile. Erst die Quality Gates konfigurieren — und zwar so, dass sie halten. Dann fünf protokollierte Läufe auswerten und daraus lesen, welche Auftragsart am meisten Nachbesserung braucht. Der zweite Teil ist der lehrreichere, weil er eine Erfahrung vermittelt, die man sonst erst nach Monaten macht.

8:43 Tests, Typprüfung, statische Analyse, Scan nach Geheimnissen und ein verpflichtendes Diff-Review sollen den Merge nachweislich blockieren — nachweislich heißt: Sie probieren es aus. Dann werten Sie die fünf Läufe nach Auftragsart aus und benennen die schwächste samt einer Vermutung zur Ursache. Und der Hinweis ist ernst gemeint: Wer die Vermutung nicht belegen kann, hat zu wenig über den Weg protokolliert. Auch das ist ein Ergebnis.

9:09 Der erste Punkt ist die Probe, die fast immer ausgelassen wird: Die Schranken werden gesetzt, aber nicht gegen einen Umgehungsversuch geprüft. Der zweite ist genau der Fehler aus dem vierten Kapitel — fünf Läufe werden gemittelt statt nach Auftragsart getrennt. Und der vierte ist der, der über den Wert der ganzen Übung entscheidet: Aus der Auswertung folgt keine Änderung an Auftrag oder Kontext.

9:31 Damit endet Tag zwei — morgen geht es um die Sicherheit.