Prüfen und sauber halten — Cheat Sheet

Der Spickzettel für die Seite nach dem Agentenlauf: Woran man Qualität festmacht, was die Tests wirklich belegen, was die Maschine prüfen kann und worauf man im Diff sieht. Zum Lernen der Methode taugt er nicht; dafür ist das Seminar Clean Code und KI-gestützte Entwicklung da. Das Gegenstück für die Seite davor ist das Blatt Auftrag und Kontext.

Vier Qualitätsziele

Gröber als eine Norm und absichtlich so — genormte Referenz wäre ISO/IEC 25010 in der Fassung von 2023 mit neun Merkmalen (nicht den acht von 2011).

Innere Qualität ist der Preis der zukünftigen äußeren: Ein System kann heute tadellos liefern und in zwei Jahren unbezahlbar sein. Die Kurven kreuzen sich früh — wer wirklich nur Wochen plant, darf sparen, aber dieser Fall kommt fast nie vor.

Was sich unter Agenten verschiebt

Praktische Folge: Konsistenz wird wertvoller, und Wissen, das nur in Köpfen existiert, wird teurer.

DRY: Wissen, nicht Syntax

Zufällig gleiche Regeln entwickeln sich unabhängig weiter. Wer sie zusammenführt, koppelt zwei Dinge und verteuert die nächste Änderung. Duplikation ist billiger als die falsche Abstraktion — aber nicht als die richtige.

SRP: nach Änderungsanlass schneiden, nicht nach Zeilenzahl

Drei Auslöser, drei Interessengruppen, ein Codeblock — deshalb bei jeder Änderung das Risiko für die anderen beiden. Die Akteure stehen in der Organisation, sie werden nicht geraten.

Modul: Clean Code als Qualitätsmodell

Struktur, Kopplung und SOLID

Parnas 1972: Am Ablauf zu zerlegen ist fast immer falsch — besser entlang der Entscheidungen, die sich ändern werden.

Woran man den falschen Schnitt merkt: Jeder Test einer fachlichen Regel braucht eine Datenbank. Dann liegt die Regel in derselben Funktion wie der Zugriff, und sie lässt sich nicht mehr allein durchdenken, weil man sie nicht allein sieht.

Abhängigkeitsrichtung

Das ist der belastbare Kern der Abhängigkeitsumkehr — er gilt in jeder Sprache und braucht oft kein Interface. Stabil heißt dabei änderungsarm, nicht zuverlässig.

SOLID: dieselben Buchstaben, zwei Lesarten

Die linke Spalte ist brauchbar, die rechte richtet Schaden an. Kopplung liest man an der Testeinrichtung ab, nicht an der Zahl der Importe — eine Metrik dafür gibt es seit 1974 nicht.

Modul: Struktur, Kopplung und SOLID als Heuristik

Teststrategie für generierten Code

Nicht die Erzeugungsgeschwindigkeit bestimmt das Tempo, sondern die Größe der geprüften Fläche.

Woraus der Test abgeleitet wird

Genau der zweite Fall tritt ein, wenn man einem Agenten Code vorlegt und um Tests bittet.

Vier Reichweiten

Die Pyramide empfiehlt viele kleine und wenige große — als Ausgangspunkt vernünftig, als Vorschrift nicht. Liegt das Risiko im Zusammenspiel, sind mittlere Tests wirtschaftlicher.

Wann welches Vorgehen

Characterization Test nach Michael Feathers, Working Effectively with Legacy Code (2004): Sie beschreiben, was das System heute tut — nicht, dass es richtig ist. Erst festgehaltenes Verhalten lässt sich absichtlich ändern statt versehentlich.

Die Gegenprobe

Die eine Frage, die alles abkürzt: Welche Zeile im Code kann ich verändern, ohne dass ein Test rot wird? Drei Zeilen absichtlich brechen und zählen, was rot wird, genügt als Stichprobe. Das große Vorbild ist Mutationstesten bei Google (Petrović und Ivanković, IEEE TSE 2021, über 24 000 Entwickler) — dort gilt Mutationsvollständigkeit ausdrücklich als weder praktikabel noch wünschenswert.

Beim Regressionstest gilt das Nachweisprinzip: den roten Lauf selbst sehen. Test und Korrektur zusammen zu beauftragen heißt, ihn nie zu sehen.

Modul: Teststrategie für KI-generierten Code

Automatische Prüfungen

Für generierten Code sind alle drei wertvoller als früher — das Volumen steigt, und eine Maschine ermüdet nicht. Der zweite Nutzen gilt nur für Agenten: Ein Übersetzungs- oder Linter-Fehler ist eine maschinenlesbare Rückmeldung, mit der sich der Agent selbst korrigiert. Damit wandert die Prüfung vor den Review statt hinein.

Typen arbeiten lassen

// prüft nichts: jeder Zustand ist darstellbar
type FahrtEntwurf = { zweck?: Fahrtzweck };

// prüft: eine erfasste Fahrt ohne Zweck gibt es nicht
type Fahrt =
  | { status: "offen" }
  | { status: "erfasst"; zweck: Fahrtzweck };

Fehlermeldungen für Mensch und Agent

// unbrauchbar
throw new Error("Buchung ungültig");

// brauchbar: Erwartung, Beobachtung, Ort
throw new Error(
  `Buchung ${id}: bis (${bis}) muss nach von (${von}) liegen`,
);

Der Leser hat keinen Kontext außer diesem Text — beim Agenten gilt das buchstäblich.

Abdeckung richtig lesen

Brian Marick: „Ich erwarte eine hohe Abdeckung. Manchmal verlangt ein Manager eine. Ein feiner Unterschied.” Keine Prozentzahl als Ziel ausgeben — sie wird erreicht statt erarbeitet.

Drei Prüfungen für die Pipeline

Zum Kontext: Erfundene Paketnamen sind gemessen. 2025 lagen 16 Modelle zwischen 5,2 und 21,7 Prozent, 2026 fünf Frontier-Modelle zwischen 4,6 und 6,1 — die Rate sinkt, die Streuung verschwindet. Von 127 wiederkehrenden Namen waren 53 registrierbar; reproduzierbar heißt angreifbar.

Architekturregeln als Fitness Functions

Begriff nach Ford, Parsons und Kua, Building Evolutionary Architectures. Ein Agent kann eine Prosa-Vorgabe übersehen, einen roten Test nicht. Der Anspruch ist Verlagerung, nicht Vollständigkeit.

Modul: Automatisierte Qualitätsprüfungen

Review: der Diff, nicht die Zusammenfassung

Ein lesbarer Diff setzt Vorarbeit voraus: sauberer Ausgangszustand, klein beauftragt, Formatierung automatisiert. Ohne diese drei ist Diff-first ein frommer Wunsch.

Drei Arten, vom Auftrag abzuweichen

Die dritte ist die häufigste und am schwersten zu erkennen — Überzeugungskraft und Richtigkeit sind entkoppelt.

Fünf Risikokategorien in fester Reihenfolge

Feste Reihenfolge, weil beim freien Lesen zuverlässig die Kategorie übersehen wird, an die man gerade nicht denkt.

KI als zweite Perspektive

Wann verwerfen besser ist als nachbessern: Die Änderung beruht auf einem grundlegenden Missverständnis · sie ist so groß, dass niemand sie vollständig gelesen hat · nach jeder Korrekturrunde entstehen neue Probleme woanders · man ertappt sich beim Gedanken, es selbst schneller zu können. Verwerfen ist kein Verlust, sondern der Ertrag der ersten Runde — der zweite Auftrag ist schärfer.

Modul: Review von KI-generierten Änderungen

Verstehen und Refactoring

Dynamische Aufrufe, Konfiguration und zur Laufzeit gebildete Namen findet kein Leser — auch kein guter. Bei ausschließenden Aussagen ist die Ausführung der einzige belastbare Weg.

Die vier Angaben im Refactoring-Auftrag

Das Abbruchkriterium fehlt fast immer und ist das wichtigste — ein Umbau, der größer wird als gedacht, ist der Normalfall.

Schrittgröße

Bei agentischer Arbeit muss die Schrittgröße vorgegeben werden — von sich aus wählt ein Agent die große Lösung, weil ihn jeder zusätzliche Schritt nichts kostet.

Modul: KI-gestütztes Codeverständnis und Refactoring

Typische Fallen

• Die Begründung lesen statt den Code. Sie ist der überzeugendere Teil — und Nachfragen, ob es stimmt, liefert wieder nur einen Vorschlag.
• Grünen Tests glauben, die zufällig nur einen Fall im Bestand haben.
• Eine Abdeckungsquote beauftragen. Sie wird erreicht, und zwar wörtlich. Dasselbe Muster bei der Testmenge und bei jeder Aktivitätszahl: Wird ein Maß zum Ziel, hört es auf, ein gutes Maß zu sein.
• Tests weniger skeptisch prüfen als den Code — sie tragen danach das Vertrauen. Häufigste Schwächen generierter Tests: keine Feststellungen, zu viele Attrappen, an Interna geklammert.
• Erst den Code bauen lassen und dann um Tests bitten.
• Zweihundert Linter-Hinweise je Lauf ausgeben. Sie werden ignoriert und wirken nicht — wenige Regeln, die wirklich gelten, wirken mehr als viele, die nur mahnen.
• Eine Pipeline dulden, die sporadisch grundlos scheitert. Sie erzieht zum Wegsehen, danach wirkt auch der echte Fehlschlag nicht mehr.
• Vollständigkeit am Umfang ablesen statt am schwierigen Fall — und eine stimmige Lösung für eine richtige halten.
• Die Nicht-Ziele nicht mitlesen. Dann fällt das Zuviel gar nicht auf, und die Beweislast dreht sich um: Plötzlich muss das Streichen begründet werden.
• Aufräumen, wo kein Änderungsdruck besteht, und die Zahl der Code-Smell- Befunde für ein Maß der Dringlichkeit halten.
• Ohne Absicherung umbauen und es Refactoring nennen — oder beim Charakterisieren gleich mitkorrigieren, was falsch aussieht.
• Weitermachen, weil schon so viel Arbeit hineingeflossen ist.
• SOLID als Checkliste vor dem Schreiben abarbeiten — oder es pauschal für überholt erklären. Die Diagnosefragen bleiben brauchbar.

Zum Seminar Clean Code und KI-gestützte Entwicklung