Dieser Workflow ist ein Arbeitsablauf, der industrielles Qualitätsmanagement — Risikoeinstufung, Abnahmekriterien, Risikoregister, Mini-FMEA, Rückfallprüfung — auf die Zusammenarbeit mit einem KI-Coding-Agenten überträgt. Die Industrie hat sich vor Jahrzehnten von der Vorstellung verabschiedet, dass Qualität durch gute Absichten und kompetentes Personal entsteht. Für einen KI-Agenten gilt dasselbe, nur zugespitzt.
Ein Agent ist nie unkonzentriert — hat aber auch keine Reputation zu verlieren. „Die Tests sind erfolgt“ klingt gleich überzeugend, ob es stimmt oder nicht.
Werkzeuge, die nicht darauf vertrauen, dass jemand es richtig macht, sondern es erzwingen — oder sichtbar machen, wenn davon abgewichen wurde.
Aus sieben Prüfbedingungen wird am Ende eine einzige, nicht erschleichbare Aussage: Feuerfest — oder eben nicht.
Jeder Änderungsauftrag durchläuft dieselben Stationen — unabhängig davon, wie klein er wirkt. Die Reihenfolge ist der eigentliche Mechanismus: Die Prüfung entsteht vor der Umsetzung, die Sicherung vor dem ersten Schreibzugriff, die Abnahmekriterien vor der ersten Zeile Code.
Regeln, die der Agent liest und befolgen soll. Wirken nur, wenn er sie tatsächlich befolgt — kein technischer Zwang.
Prüfungen, die unabhängig vom Willen des Agenten laufen: Pre-Commit-Hook, CI-Testlauf, Lint-Gate, Geheimnisprüfung, Abnahme-Gate. Nicht überredbar, nicht übersehbar.
Wo immer möglich wird eine textuelle Regel zusätzlich mechanisch abgesichert — statt sich allein darauf zu verlassen, dass sie gelesen wurde.
Der Workflow reicht vom Zielverständnis bis zur Freigabe „Feuerfest“; vier Rückführungen halten ihn auf dem Ziel. Auf schmalen Bildschirmen lässt sich das Schema horizontal scrollen.
Der Workflow ist nicht linear. Am Ende jeder Aktivität steht die Frage, ob das Ziel noch getroffen wird — verneint, führt eine definierte Schleife an genau eine frühere Station zurück.
Die Schleifen sind der Grund, warum das Zielverständnis am Anfang steht und nicht nur einmal gilt: jede Rückführung prüft es erneut gegen belegte statt angenommene Fakten.
Der Auftrag, wie er gemeint war — nicht wie er verstanden wurde.
Gewünschtes, bisheriges und ausdrücklich unverändertes Verhalten.
Offene Annahmen wandern ins Register, statt still im Code zu landen.
Der echte Programmweg, vom Eingang bis zur fachlichen Ausgabe.
Dokumentiert. „Tests erfolgreich“ ohne Angabe gilt als nicht erbracht.
Jede Anforderung braucht mindestens eine Prüfung, jede Prüfung ein dokumentiertes Ergebnis. Das wirkt pedantisch — es ist aber genau die Eigenschaft, die in langen Sitzungen als erste verloren geht: die stille Verengung des Umfangs.
Darstellung oder Dokumentation, kein Verhaltenswechsel, keine offene Annahme.
→ Abnahmekriterien, gezielte Prüfung, dokumentierte Feststellung ohne wesentliche Risikowirkung.
Funktionale Änderung mit begrenzter Wirkung — oder eine offene Annahme, die den Auftrag nicht überdauert.
→ volle Abnahmekriterien, Rückfall- und Integrationsprüfung, Registereintrag je offener Annahme, Kennzeichnung im Bericht.
Möglicher Datenverlust, Geheimnis- oder Datenschutzbezug, geänderte Schnittstellen oder Datenformate, mehrere offene Annahmen, mehr als eine Anwendungsschicht.
→ alles aus Stufe 2, dazu Registereintrag unabhängig von der Auflösung, ausdrückliche Freigabe vor der Umsetzung und eine aktuelle Mini-FMEA je berührtem Funktionsbereich.
Gering, normal, erhöht — nach festen Kriterien. Die Weiche, ohne die entweder jede Kleinigkeit im Prozess erstickt oder der Prozess beim ersten Ernstfall versagt.
Überführt eine offene technische Annahme in eine belegte — bevor die volle Spec-First-Kette für einen möglicherweise ungeeigneten Ansatz aufgesetzt wird.
Abnahmekriterium → fehlschlagende Prüfung → Umsetzung → bestandene Prüfung. Eine Prüfung, die schon vor der Korrektur grün ist, obwohl sie den Fehler nachweisen soll, ist untauglich.
Sicherung vor dem ersten Schreibzugriff. Danach die kleinste zusammenhängende Änderung, die alle Kriterien erfüllt — keine Umbenennungen, keine Bibliothekswechsel, keine Formatierungswellen nebenbei.
Auch mehrere einzeln zulässige Änderungen können zusammen ein nicht beauftragtes Ziel verfolgen — etwa die schrittweise Aufweichung derselben Prüfregel. Erkannt heißt: anhalten, Gesamtwirkung offenlegen, ins Register.
Aus einem Wunsch wird eine prüfbare Aussage: Fehlerfälle, Randfälle, betroffene und ausdrücklich nicht betroffene Programmteile.
Die einzige Methode, die projektweite, sitzungsübergreifende Risiken festhält. Genau dort, wo chatbasiertes Entwickeln sonst scheitert: Wissen geht zwischen Sitzungen verloren.
Sechs bis zehn Fehlermodi, bewertet nach Schwere, Auftreten, Entdeckung. Bewusst knapp: „Was könnte hier schiefgehen“ wird zur strukturierten Frage statt zum Bauchgefühl am Ende.
Jeder behobene Fehler bekommt eine dauerhafte Prüfung. Nicht aus Misstrauen — sondern weil er sonst irgendwann in einem hübschen neuen Kleid zurückkommt.
Kein „habe ich erledigt“, sondern: geänderte Dateien, nachgewiesene Ursache, tatsächlich gelaufene Prüfungen, bleibende Einschränkungen, neue Registereinträge.
Entscheidungen mit Begründung, offene Punkte, bekannte Einschränkungen — fortgeschrieben, nicht überschrieben. Damit die nächste Sitzung nicht bei Null anfängt.
Die jüngste Regel — und die selbstkritischste: Bevor eine Aufräum-Empfehlung einen bestehenden Sicherungsmechanismus berührt, muss geprüft werden, welches Erkennungssignal dabei verloren ginge.
Nicht „fertig“, nicht „gemerged“ — eine Zusicherung, die einem echten Belastungstest standhält. Ein eigenes Skript — das Abnahme-Gate — prüft die Bedingungen, losgelöst davon, wie überzeugend der Abschlussbericht formuliert ist. Fehlt eine, benennt es sie einzeln. Erst wenn alle zutreffen, entsteht ein Eintrag in einer versionierten Nachweisdatei — mit Kennung auf genau den geprüften Commit.
Der Punkt ist nicht das Label. Der Punkt ist, dass es sich nicht erschleichen lässt — weder vom Agenten durch eine gute Zusammenfassung, noch von mir selbst durch Ungeduld am Ende eines langen Arbeitstags.
Diese sechs Sätze sind die unscheinbarste Regel des ganzen Werks — und die wirksamste. Sie verwandeln eine Erfolgsbehauptung in einen nachprüfbaren Beleg — oder legen offen, dass es keinen gab.
Die schärfste Probe bestand der Ansatz an sich selbst. Ein Werkzeug zu bauen, das verfrühte „fertig“-Meldungen abfängt, ist nicht der Schlusspunkt — sondern eine weitere Ebene, die derselben Skepsis unterliegt wie alles davor.
Diese Methodik ist nicht am Schreibtisch entworfen, sondern aus laufenden Projekten entstanden — dort, wo die Kosten fehlender Nachprüfbarkeit unmittelbar anfallen.
Die ständige Suche nach Perfektion begleitete mein Coding. Optimierte Prompts halfen zwar punktuell, die Qualität der Ergebnisse zu verbessern, führten jedoch nicht dauerhaft zu einem verlässlich hohen Niveau.
Deshalb verlagerte sich seit Monaten meine Aufmerksamkeit vom nächsten Code-Feature auf eine grundsätzlichere Frage: Wie muss ein Arbeitsablauf gestaltet sein, damit auch ein Autodidakt wiederholt zu belastbaren und reproduzierbaren Ergebnissen gelangt?
Dafür musste der verbleibende Spielraum für Fehler, Interpretationen und vorschnelle Erfolgsmeldungen möglichst gegen null gehen. Die Antwort lag nicht in immer ausgefeilteren Prompts, sondern in bewährten Werkzeugen, die seit Jahrzehnten dort eingesetzt werden, wo ein bloßes „Erledigt!“ nicht als Nachweis genügt.
Skills sind textuelle Anleitungen, die der Agent selbst lädt, wenn er einen Anlass erkennt. Sie wirken nur, wenn er sie befolgt.
Hooks sind kleine Skripte, die bei bestimmten Ereignissen ohnehin laufen — unabhängig davon, was der Agent in dem Moment von der Sache hält. Sie lassen sich nicht überreden.
Diese Zweiteilung bringt die Plattform mit. Was hinzukommen musste, ist der Inhalt, der darauf aufsetzt — und das ist der eigentlich interessante Teil.
Das eigentliche Missverhältnis liegt zwischen wachsendem Tokenverbrauch und stagnierender Ergebnisqualität.
Jeder zusätzliche Korrekturdurchlauf erhöht den Verbrauch — ohne sicherzustellen, dass die Qualität im gleichen Maß steigt.
Der vollständige Workflow liegt in einer einzigen Datei: die Regeln, die Einstufungskriterien, die Vorlagen und die Bedingungen für „Feuerfest“. Der Workflow wird für die nicht-kommerzielle Nutzung unter CC BY-NC-SA 4.0 auf Anfrage per E-Mail gern an Sie versendet. Jede kommerzielle Nutzung — Verkauf, bezahlte Produkte oder Dienstleistungen, Schulung und Beratung auf dieser Basis — ist nur nach ausdrücklicher, schriftlicher Zustimmung gestattet.
Deine Wege entstehen beim Gehen — alle Features entstehen erst beim Durchlaufen des Workflows im eigenen Projekt; nichts davon muss mitgeliefert werden.
Risikoeinstufung, belegte gegen offene Annahmen, Abnahmekriterien, Risikoregister, Prüfmatrix, Mini-FMEA, Systemtest und Rückfallprüfung, Abschlussbericht, Freigabe „Feuerfest“.
Ein KI-Coding-Agent mit Skills und Hooks, ein versioniertes Projekt und eine Prüfsammlung, die sich vollständig ausführen lässt. Die Methodik selbst ist werkzeugunabhängig.
Nicht-kommerziell unter CC BY-NC-SA 4.0, kommerzielle Nutzung nur nach schriftlicher Zustimmung. Lizenz lesen →
Am wertvollsten ist der Fall, in dem die Methodik nicht getragen hat. Wenn Sie das Kit einsetzen und dabei auf eine Lücke stoßen: gern eine Zeile. Antwort nicht garantiert, gelesen wird alles.