Was industrielles Qualitätsmanagement einem KI-Coding-Agenten beibringt

Die Industrie hat sich schon vor Jahrzehnten von der Vorstellung verabschiedet, dass man Qualität durch gute Absichten und kompetentes Personal sicherstellt. Zu viel hängt davon ab – etwa im Flug- und Fahrzeugbau –, ob jemand einen Schritt vergessen hat, ob eine Annahme unausgesprochen blieb und ob sich diese Person an die vom QM-System vorgegebene Checkliste – hier den Workflow – hielt oder nicht.

Die Methodik dafür geben FMEA, QFD, Risikoregister, Abnahmekriterien und formalisierte Abschlussberichte vor – Werkzeuge, die nicht darauf vertrauen, dass jemand es schon richtig macht, sondern es erzwingen oder wenigstens sichtbar machen, wenn davon abgewichen wird.

Ein KI-Agent hat genau dasselbe Grundproblem, nur zugespitzt: Er ist nie unkonzentriert, aber er hat auch keine Reputation zu verlieren, kein schlechtes Gewissen und keine Scheu, eine Behauptung wie „Die Tests sind erfolgt“ so selbstbewusst zu formulieren, obwohl sie nicht stimmt und man sie ihm dennoch abnimmt. Genau deshalb passen diese alten, unglamourösen QM-Werkzeuge aus der Industrie überraschend gut auch in Software-Workflow-Szenarien.

Zwei Ebenen: was die Plattform mitbringt, was ich mitgebracht habe

Ausgehend von eigenen Softwareprojekten entwickelte ich zunächst unter Linux zunehmend komplexere Python-Programme, die auch als Windows-App umgesetzt und später teilweise auf macOS portiert wurden. Die Arbeit über mehrere Plattformen hinweg zeigte früh, dass zuverlässige Softwareentwicklung mehr erfordert als funktionierenden Code: klare Anforderungen, reproduzierbare Abläufe, kontrollierte Änderungen und belastbare Prüfungen. Diese Erfahrung wurde zum Ausgangspunkt für einen Entwicklungsworkflow, der speziell auf die Zusammenarbeit mit KI-Coding-Agenten zugeschnitten ist.

Ein moderner KI-Coding-Agent bringt, den KI-Entwicklern sei’s gedankt, bereits zwei geniale Bordmittel mit, auf denen sich so ziemlich alles aufbauen lässt. Skills sind textuelle Anleitungen, die der Agent selbst lädt, wenn er einen passenden Anlass erkennt – eine unklare Fehlerursache, eine neue Protokollierung. Sie wirken nur, wenn er sie tatsächlich befolgt.

Und dann gibt es Hooks, kleine Skripte, die bei bestimmten Ereignissen automatisch laufen – vor dem ersten Schreibzugriff, nach einem Werkzeugaufruf, beim Sitzungsende – unabhängig davon, was der Agent in dem Moment gerade „… von der ganzen Sache hält“. Sie lassen sich nicht überreden, weil sie für seine Argumente einfach kein „offenes Ohr“ haben.

Diese Zweiteilung, textuell vs. mechanisch, ist dann eine Plattform-Infrastruktur, die das Modell schon mitbringt. Was ich mitgebracht habe, ist der Inhalt, der auf diesen beiden Ebenen aufsetzt – und das ist vielleicht der eigentlich interessante Teil.

Risikoeinstufung: nicht jede Änderung verdient denselben Aufwand

Jede Änderung wird zuerst in eine von drei Klassen eingestuft – gering, normal, erhöht – nach klaren Kriterien: Kann Datenverlust auftreten? Geht es um Geheimnisse oder Datenschutz? Werden öffentliche Schnittstellen verändert? Bleibt eine Annahme offen, die sich nicht auflösen lässt? Diese Einstufung ist keine Formalität, sondern steuert alles Weitere: Eine Formulierungskorrektur in der Dokumentation braucht kein Risikoregister und keine Mini-FMEA (siehe unten). Eine Änderung an einem Datenformat schon. Ohne diese Weiche würde entweder jede Kleinigkeit im Prozess ersticken oder der Prozess bei der entscheidenden Änderung versagen.

Proof of Concept: eine offene Frage bekommt einen eigenen, befristeten Raum

Mein Workflow hatte aktuell eine unadressierte Stelle: Ein Abschnitt unterscheidet zwischen belegten und offenen Annahmen und verlangt, dass eine Annahme nur dann als belegt gilt, wenn sie „durch vorhandenen Code, vorhandene Dokumentation, eine tatsächlich ausgeführte Prüfung oder eine ausdrückliche Bestätigung des Auftraggebers“ nachgewiesen ist. Was fehlte, war ein methodischer Weg, genau diesen Nachweis zu erbringen, bevor die volle Spec-First-/Test-First-Kette für einen möglicherweise ungeeigneten technischen Ansatz aufgesetzt wird. Ein zeitlich begrenzter Proof of Concept ist genau dieses fehlende Werkzeug: Er überführt eine offene technische Annahme in eine belegte, ohne dass man dafür bereits Abnahmekriterien, Rückfallprüfung und Risikoregister-Einträge für einen Weg pflegt, der sich als Sackgasse erweisen könnte.

Ebenso wichtig ist die Abgrenzung nach unten: Ein Proof of Concept und eine schlicht direkt ausgeführte Prüfung sind zwei Werkzeuge für zwei Lagen. Der Proof of Concept klärt eine Annahme, die sich nur durch einen befristeten Versuch belegen lässt; eine Frage dagegen, die schlicht nie gestellt wurde, verlangt keine Vorstudie, sondern nur die eine, direkt beantwortbare Prüfung. Vor dem großen Prozess lohnt daher die kurze Rückfrage, welches der beiden die Lage wirklich verlangt – sonst setzt man einen langen Ablauf auf, wo eine einzige richtige Frage genügt hätte.

Abnahmekriterien und Risikoregister: aus einem Wunsch wird eine prüfbare Aussage

Bevor irgendetwas umgesetzt wird, muss der Auftrag in prüfbare Kriterien übersetzt sein: gewünschtes Verhalten, bisheriges Verhalten, ausdrücklich unverändertes Verhalten, Fehlerfälle, Randfälle, betroffene und ausdrücklich nicht betroffene Programmteile. Eine unvermeidbare Annahme wird dabei nicht stillschweigend in den Code übernommen, sondern benannt – und wenn sie sich innerhalb der Änderung nicht auflösen lässt, wandert sie in ein Risikoregister: eine fortlaufend geführte, versionierte Liste von Dingen, die über die einzelne Änderung hinaus im Blick bleiben müssen. Das verhindert das stille Wegnicken einer Unsicherheit, nur weil sie gerade unbequem ist.

Risikoregister – höchster zu erwartender Nutzen Mein bestehender Workflow beinhaltete bereits die Erkennung kumulativer Zielabweichung und die Session-Notiz. Beide erfassen aber nur Momentaufnahmen: Sie erkennen ein Muster, während es passiert; die Session-Notiz hält offene Punkte fest, verfolgt sie aber nicht strukturiert weiter. Ein Risikoregister schließt genau diese Lücke – es ist die einzige Methode, die explizit projektweite, sitzungsübergreifende Risiken (z. B. schleichende technische Schulden, wachsende Abhängigkeit von einer API) festhält. Das ist genau das Problem, an dem chatbasierte Entwicklung typischerweise scheitern kann: Wissen geht zwischen Sitzungen verloren. Deshalb ist hier die Verbesserung am direktesten spürbar.

Die QFD-Matrix: jede Anforderung bekommt eine Prüfung, jede Prüfung ein Ergebnis

Aus dem Quality Function Deployment (QFD) stammt der Grundgedanke, eine Anforderung lückenlos bis zur tatsächlichen Prüfung durchzuverfolgen. Die volle QFD-Gewichtungs- und Wechselwirkungsmatrix, das berühmte „House of Quality“, habe ich mir bewusst nicht geholt – für ein Einzelprojekt schlicht unverhältnismäßig. Übernommen habe ich nur die Kette dahinter: Anforderung → Abnahmekriterium → Risiko → Prüfung → Ergebnis, bei höherem Risiko mit eigenen Kennungen, damit sich jeder Schritt eindeutig zurückverfolgen lässt. Das mag pedantisch wirken, ist aber genau die Eigenschaft, die einem Agenten am ehesten fehlt, wenn er „unter Druck“ gerät – und das passiert in längeren Chats: die stille Verengung des Umfangs. Eine Matrix verlangt, dass jede Anforderung mindestens eine Prüfung hat und jede Prüfung ein dokumentiertes Ergebnis vorweist.

Mini-FMEA: Fehler vorwegnehmen, bevor sie passieren

Bei Änderungen mit erhöhtem Risiko kommt eine kompakte Fehlermöglichkeits- und Einflussanalyse zum Einsatz: Für jeden betroffenen Teilbereich wird der wahrscheinlichste Fehlermodus benannt, seine Folge, seine Ursache, was ihn bereits verhindern und was ihn bereits entdecken würde – bewertet nach Schwere, Auftretenswahrscheinlichkeit und Entdeckungswahrscheinlichkeit; daraus wird eine Handlungspriorität abgeleitet. Die FMEA.md ist als Pflichtartefakt in der vorgeschlagenen Ordnerstruktur bewusst knapp gehalten: sechs bis zehn Fehlermodi, keine Vollständigkeitsinflation. Der Wert liegt nicht in epischer Länge, sondern darin, dass „Was könnte hier konkret schiefgehen?“ zu einer strukturierten Frage wird statt zu einem vagen Bauchgefühl-Check am Ende.

Ausprobiert an einem echten Stufe-3-Fall habe ich das Format tatsächlich schon einmal – nur ohne dass am Ende eine Mini-FMEA dabei herauskam. Der bisher einzige reale Stufe-3-Fall bei mir war ein kompletter Ordnerumzug meines gesamten Arbeitsbereichs. Der durchlief den vollen Stufe-3-Prozess, einschließlich einer eigenen Rückverfolgbarkeitsdatei – eine Mini-FMEA wurde dafür aber bewusst nicht angelegt, mit dokumentierter Begründung: reine Infrastrukturänderung, keine fachliche Funktion der Anwendung betroffen. Auch das musste ich mir selbst begründen lassen, nicht nur behaupten. Eine tatsächlich geschriebene Mini-FMEA-Datei gibt es also bis heute nicht – weil noch kein Stufe-3-Fall aufgetreten ist, der wirklich eine Funktion der Anwendung selbst berührt. Auch das gehört in diesen Text.

Systemtest, Ende-zu-Ende-Test und Rückfallprüfung: nur der echte Weg zählt

Ein Unit-Test beweist, dass eine Funktion für sich funktioniert – nicht, dass der tatsächliche Programmweg funktioniert. Deshalb zählt als vollständiger Nachweis nur ein Test, der wirklich den produktiven Code vom Eingang bis zur fachlichen Ausgabe durchläuft; externe Grenzen wie Netzwerk oder Uhrzeit dürfen kontrolliert ersetzt werden, alles dazwischen muss echt sein. Und jeder behobene Fehler bekommt eine dauerhafte Rückfallprüfung, die eine Wiederholung technisch verhindert – nicht, weil man dem Agenten (oder sich selbst) misstraut, sondern weil ein einmal gefundener Fehler sonst irgendwann in einem hübschen neuen Kleidchen zurückkommt. Ziel ist der Nachweis: Die vollständige Prüfsammlung (pytest) ist grün, einschließlich einer neuen oder angepassten Rückfallprüfung, die den behobenen Fehler abdeckt.

Der Abschlussbericht: nichts ist fertig, nur weil es behauptet wird

Am Ende steht kein „Habe ich erledigt“, sondern ein strukturierter Bericht: welche Dateien geändert wurden, welche Ursache nachgewiesen wurde, welche Prüfungen tatsächlich liefen und mit welchem Ergebnis, welche Einschränkungen bleiben, welche Risikostufe die Änderung hatte, welche Risikoregister-Einträge neu entstanden sind. Ein bloßes „Tests erfolgreich“ ohne Angabe der ausgeführten Prüfung gilt ausdrücklich als nicht ausreichend. Das ist die vielleicht unscheinbarste, aber wirksamste Regel von allen: Sie verwandelt eine Erfolgsbehauptung in eine nachprüfbare Aussage – oder deckt auf, dass es keine war.

Der Weg zu „Feuerfest“

Alle diese Werkzeuge laufen am Ende in einer einzigen Kennzeichnung zusammen, die ich „Feuerfest“ nenne. Der Name ist bewusst gewählt: nicht „fertig“, nicht „gemerged“, sondern eine Zusicherung, die einem echten Belastungstest standhält.

Feuerfest wird nicht behauptet, sondern durch ein eigenes Skript geprüft – losgelöst davon, wie überzeugend der Abschlussbericht formuliert ist: Testlauf grün, Sicherung vorhanden und geprüft, Geheimnisprüfung bestanden, Dokumentation aktuell, kein offener Hochrisiko-Eintrag im Risikoregister, Prüfmatrix im geforderten Umfang vollständig, bei erhöhtem Risiko eine aktuelle Mini-FMEA. Erst wenn wirklich alle Bedingungen zutreffen, vergibt das Skript den Status und schreibt einen Eintrag in eine versionierte Nachweisdatei – mit einer eigenen Kennung, die auf genau den geprüften Commit verweist. Fehlt auch nur eine Bedingung, wird „Feuerfest“ nicht vergeben – es bleibt bei den einzelnen Status-Ampeln, nicht bei einer pauschalen Behauptung; das Skript benennt dann sogar einzeln, welche Bedingung fehlt.

Der Punkt an „Feuerfest“ ist nicht das Label selbst, sondern dass es sich nicht erschleichen lässt – weder vom Agenten durch eine überzeugend formulierte Zusammenfassung noch von mir selbst durch Ungeduld am Ende eines langen Arbeitstags. Es ist der Moment, in dem aus sieben Prüfbedingungen eine einzige, ehrliche Ja-oder-Nein-Aussage wird: Hop oder Top.

Wenn das Prüfwerkzeug selbst zum Risiko wird

Die neueste Regel kam nicht aus der Industrie, sondern aus einem Fehler, den ich fast zweimal hintereinander gemacht hätte. Claude Code hat einen eingebauten Systemcheck, der unter anderem ungenutzte Skills aufspürt und vorschlägt, sie abzuschalten – reiner Kontext-Aufräumdienst, klingt harmlos. Ich hatte ihn laufen lassen, weil mich eine Auto-Update-Meldung dazu aufgefordert hatte, und er fand vier Skills mit null Nutzung.

Zwei davon waren aber gezielt für seltene, echte Situationen gebaut – der eine feuert nur, wenn ich ein komplett neues Projekt aufsetze, der andere nur, wenn eine neue Protokollierung geschrieben wird. Die Frage war: Wie stellt man sicher, dass so ein abgeschaltetes Werkzeug bei Bedarf zuverlässig wieder anspringt? Die ehrliche Antwort: gar nicht. Die Beschreibungszeile in der Werkzeugliste ist der einzige Mechanismus, über den überhaupt erkannt wird: „Diese Situation passt dazu.“ Genau diese Zeile verschwindet mit dem Abschalten. Ein harmlos klingender Aufräumvorschlag hätte, unreflektiert übernommen, eine echte Erkennungslücke geschaffen.

Kurz danach derselbe Fehler noch einmal, eine Ebene tiefer: Der Systemcheck schlug vor, zwei seltener gebrauchte Regelabschnitte – Machbarkeitsvorstudie und Mini-FMEA – aus der immer geladenen Kerndatei in separate, bei Bedarf ladende Werkzeuge auszulagern. Kontext sparen, klingt vernünftig. Erst beim genauen Hinsehen fiel das Henne-Ei-Problem auf: Die Fähigkeit, zu erkennen, „Hier bräuchte ich jetzt eine Mini-FMEA“, hängt bislang genau daran, dass der vollständige Regeltext vorliegt, wenn eine Änderung eingestuft wird. Verschiebt man den Inhalt in ein Werkzeug, das erst bei erkanntem Anlass lädt, entsteht eine Erkennung, die von genau dem Wissen abhängt, das nicht mehr da ist.

Beide Male kam die eigentliche Analyse erst auf Nachfrage – nicht von selbst, nicht vorab. Das ist der eigentliche Befund: Ein Prüfwerkzeug urteilt rein mechanisch, nach Nutzungszahl und Zeichenzahl, ohne zu wissen, welche fachliche Rolle ein Werkzeug oder ein Regelabschnitt im eigenen System spielt. Das ist kein Fehler des Prüfwerkzeugs – das kann es strukturell nicht wissen. Der eigentliche Fehler lag darin, eine Empfehlung weiterzureichen, statt sie selbst gegen genau die Frage zu prüfen, die dann jedes Mal von außen kam.

Die Konsequenz daraus wurde selbst zu einer neuen, fest verankerten Regel: Bevor eine Empfehlung – ob von einem Prüfwerkzeug oder als eigener erster Vorschlag – einen bestehenden Sicherungsmechanismus betrifft, muss vorab und ausdrücklich geprüft werden, welches Erkennungssignal dabei verloren ginge, ob es ersetzbar ist, und ob die Erkennung des Auslösers selbst an genau dem Inhalt hängt, der verschoben werden soll. Nicht erst auf Nachfrage – von Anfang an Teil der Vorlage selbst.

Das eigentlich Interessante daran: Diese Regel ist selbst wieder nur ein Beispiel für das ganze Prinzip dieses Texts. Keine neue Erfindung – nur die konsequente Anwendung derselben Idee, Vertrauen durch Nachprüfbarkeit zu ersetzen, auf die Werkzeuge, die genau das eigentlich schon längst leisten sollten.

Keines dieser Werkzeuge ist wirklich originell und schon gar nicht von mir erfunden. Das ist genau der Punkt. Sie existieren seit Jahrzehnten, sie haben sich bewährt und sie wurden für Situationen entwickelt, in denen man sich auf die reine Zusicherung „Erledigt!“ nicht verlassen will oder darf. Genau diese Situation hat man auch mit einem KI-Agenten – nur dass er, anders als ein Mensch, weder aus Erfahrung lernt noch durch Erschöpfung gebremst wird. Zugleich werden seine eigenen Lücken vorab ehrlich benannt: „… ist eine KI und kann Fehler machen.“

Hooks und Skills liefern dafür nur die Bühne; die eigentliche Vorstellung ist die Methodik, die darauf läuft. Die Antwort auf einen KI-Agenten war nie, ihm zu misstrauen. Die Antwort war, ihm dieselbe Disziplin aufzuerlegen, die Fertigungsbetriebe längst für den „Faktor Mensch“ entwickelt haben.

Angeblich fertig: das Abnahme-Gate

In einer einzigen, langen Sitzung viermal hintereinander ein Fehler: eine Sicherung angeblich erstellt, ein Abschlussbericht angeblich vollständig, ein Hintergrundprozess angeblich beendet, eine Aufgabe angeblich fertig – vier Mal ein zu früh behauptetes „sauber“, vier Mal nur entdeckt, weil nachgefragt wurde. Nicht von einem Werkzeug. Von dem Menschen, der durch den Agenten eigentlich entlastet werden sollte.

Die Antwort darauf konnte keine weitere Regel im Fließtext sein – genau solche Regeln waren es ja, die gerade übergangen wurden. Stattdessen entstand ein kleines, bewusst stumpfes Prüfwerkzeug, das einen eigenen Namen bekam: das Abnahme-Gate. Vor jeder Aufgabe wird das Soll als Liste geschrieben, jeder Punkt an eine Tatsache gebunden, die sich maschinell nachweisen lässt – ein Prozess läuft nicht mehr, ein Arbeitsverzeichnis ist sauber, ein Testlauf endete mit Exit-Code null. Was sich nicht so ausdrücken lässt, wird ehrlich als „manuell zu prüfen“ markiert, nicht stillschweigend als erledigt behauptet. Und die letzte, eigentlich entscheidende Instanz ist kein Agent mehr, der sich selbst attestiert, sondern ein echter Commit-Hook: Er feuert beim tatsächlichen Git-Ereignis, nicht bei einer geglaubten Ankündigung, und blockiert fail-closed, sobald auch nur ein Punkt offen ist.

Der eigentlich lehrreiche Teil kam erst danach. Beim Durchsehen dieses neuen Werkzeugs fanden sich – mit derselben Methode, testgetrieben, ein Fehlschlag zuerst – zwei echte Lücken darin selbst: Eine doppelt vergebene Kennung hätte eine einzelne Freigabe zwei verschiedene Punkte zugleich abhaken lassen; ein fehlerhafter Eintrag in der Prüfliste hätte das Werkzeug mit einem stillen Absturz beendet, statt kontrolliert „nein“ zu sagen – genau die Art Fehler, die es bei anderen verhindern sollte. Kurz danach ein dritter Fund: Der Mechanismus, der überhaupt erst erzwingt, dass eine Sitzung mit einer Notiz endet, verließ sich unbemerkt auf ein Verzeichnis, das nicht mehr stimmte, sobald an anderer Stelle weitergearbeitet wurde – und blockierte deshalb störrisch, obwohl längst alles dokumentiert war.

Keiner dieser drei Funde war dramatisch. Zusammengenommen zeigen sie aber die eigentliche Konsequenz dieses ganzen Ansatzes: Ein Prüfwerkzeug zu bauen ist nicht der Schlusspunkt, sondern nur eine weitere Ebene, die selbst wieder derselben Skepsis unterliegt wie alles davor. Es gibt keine Stelle in dieser Kette, an der man aufhören darf zu prüfen, nur weil etwas gerade „der Mechanismus“ ist.

Der Ablauf noch einmal knapp:

• Auslöser: viermal „fertig“/„sauber“ behauptet, viermal zu früh – jedes Mal nur durch Nachfrage entdeckt, nicht durch ein Werkzeug.
• Konsequenz: kein weiterer Text, sondern ein externes Prüfwerkzeug – das Abnahme-Gate. Das Soll vorab als Liste, geprüft gegen Fakten statt gegen Selbstauskunft.
• Letzte Instanz: ein echter Commit-Hook – fail-closed, unabhängig davon, ob der Agent zustimmt.
• Fund 1 im Gate selbst: eine doppelt vergebene Kennung hätte zwei verschiedene Punkte mit einer einzigen Freigabe abgehakt.
• Fund 2 im Gate selbst: ein fehlerhafter Listeneintrag hätte das Werkzeug stumm abstürzen statt kontrolliert blockieren lassen.
• Fund 3, eine Ebene höher: auch der Mechanismus, der die Sitzungs-Notiz erzwingt, hatte einen eigenen blinden Fleck.
• Erkenntnis: Prüfen ist rekursiv – kein Mechanismus ist von der eigenen Prüfung ausgenommen, nur weil er „der Mechanismus“ ist.

Freigabestatus „Feuerfest“ – Ziel erreicht!

Und nicht zuletzt geht es dabei auch um das Verhältnis von Token zu Geld – oder um dessen Missverhältnis.