Fertigungsdisziplin statt Prompt Engineering: Poka-Yoke, MSA, FMEA für KI-Code

agentic-gates Blog, Zielgruppe: Entwickler, Tech Leads und Software-Architekten

Die KI-Software-Welt redet wie eine Fabrik. Pipelines, Gates, Qualitätsmetriken, ab und zu Six Sigma. Das Vokabular der Fertigungsqualität ist in den Werkzeugen angekommen. Die Disziplin dahinter nicht.

Eine echte Fabrik gibt keine Werkzeugmaschine für die Serienfertigung frei, weil der Bediener sagt, das Werkstück sehe gut aus. Sie fährt eine Prüfmittel- und Prozessfähigkeitsstudie an standardisierten Referenzteilen und misst, ob die Maschine die entscheidenden Toleranzen unter Last hält. Für einen KI-Code-Builder sucht man solche Studien meist vergeblich. Man verlässt sich darauf, dass eine Handvoll grüner Unit-Tests als Qualitätsnachweis reicht.

Grüne Tests sind kein Qualitätssiegel für stochastischen Code und Prompt Engineering ist der Grund, warum die Branche weiter darauf hofft. Einem stochastischen Modell lässt sich keine deterministische Zuverlässigkeit einreden. 95 % richtig ist okay für einen Chatbot und inakzeptabel für einen Build. Der Fix ist Prozesskontrolle, derselbe Zug, den ein Qualitätsingenieur längst kennt: qualifizieren, überwachen, eingrenzen. Nimmt man das ernst statt als Metapher, entstehen die folgenden Disziplinen. Jede davon ist laufender Code, keine Slideware und jede Behauptung trägt ihre Evidenz.

1. Poka Yoke: harte Sperren und weiche Kennzahlen

Das klassische Poka Yoke, die japanische Methode der mechanischen Fehlervorbeugung, verhindert, dass ein fehlerhaftes Teil überhaupt die nächste Station erreicht. Für KI-Code heißt das: Jede Regel gehört in eine von zwei strikt getrennten Klassen.

• Wahrheitswertige Regeln (harte Sperren). Bedingungen mit eindeutigem Wahrheitswert. Kreuzt dieser Import eine Architekturgrenze, ja oder nein. Eine Verletzung stoppt den Build, bedingungslos.
• Form-Proxies (weiche Kennzahlen). Funktionslänge, Verschachtelungstiefe und ihre Verwandten werden laufend überwacht und blockieren den Build nie.

Warum diese Trennung wichtig ist, ist selbst ein gemessenes Ergebnis und ein überraschendes.

Der Ankündigungseffekt

Wir haben präregistrierte Pilotstudien gefahren (n = 3 pro Arm, eine identische Aufgabe), an welcher Stelle der Regel-Pipeline der Gaming-Anreiz wirkt. Kündigten wir eine blockierende Form-Schwelle an, bevor der Agent entwarf, erschien in allen drei Läufen die Gaming-Signatur und das Gate löste nie aus, weil der Agent vorauseilend kooperierte. Enthüllten wir dieselbe Regel erst nach einem ersten Entwurf, sodass das Gate tatsächlich auslöst und Reparatur erzwingt, gab es in keinem der drei Läufe Gaming. Eine wahrheitswertige Regel anzukündigen, eine, die man nur erfüllen, nicht aber austricksen kann, war sauber.

Ein Hinweis zum Maßstab, bewusst dazugesagt: Unsere Pilotstudien zeigen diesen Effekt konsistent über drei Versuchsanordnungen im Pilotmaßstab. Wir sagen "unsere Pilotstudien zeigen", nicht "bewiesen".

2. Prüfmittelstudie, bevor gemessen wird

Die industrielle Messtechnik hat einen festen Grundsatz, die Messsystemanalyse: Bevor man einem Instrument traut, muss das Instrument selbst nachweislich richtig messen.

Um die eigenen Prüfungen zu qualifizieren, haben wir Fehler injiziert: 12 von 12 bekannten Antwortfällen gefangen, bei unabhängiger Neu-Validierung. Und wir haben das modische Instrument nach seinen eigenen präregistrierten Kriterien verworfen. LLM-Judges, die Code-Qualität paarweise schiedsrichtern sollten, produzierten 100 % einstimmige Urteile, die sich als Positions-Bias herausstellten: Sie wählten in 32 von 36 Urteilen die zuerst gezeigte Option und das Debiasing über beide Reihenfolgen ließ ihre Konsistenz auf null zusammenfallen. Ein negatives Ergebnis, vollständig veröffentlicht. Es ist der stärkste Grund, unseren positiven Zahlen zu trauen.

3. Industrielle Qualitätsrahmenwerke im Build

Damit KI-Erzeugung aus der Bastelecke in eine kontrollierte Fertigung kommt, nutzt der Werkzeugkasten die etablierten Instrumente des Qualitätsmanagements:

• FRACAS (Failure Reporting, Analysis and Corrective Action System). Eine automatisch gesammelte Liste entwischter Fehler samt Eindämmung.
• COPQ (Cost of Poor Quality). Die realisierten Fehlerkosten pro gemergter Änderung, verfolgt über eine gemeinsame Run-ID.
• Control-Plans. Jede Prüfung trägt einen benannten Owner und einen Reaktionsplan für Abweichungen.
• Präregistrierung. Jedes Experiment friert sein Design per Commit-Hash ein, bevor Daten existieren; Schwellen sind ohne das ungültig. Diese Disziplin gilt über alle elf Einträge unseres Experiment-Registers.

Zwei ehrliche Grenzen

Zur Ingenieursehrlichkeit gehört, die Grenzen zu benennen:

• Werkbank gegen Live-Produktion. Fähigkeitszahlen leben auf der Werkbank mit Standard-Werkstücken. Wir berechnen bewusst keine Fähigkeitsindizes über live laufende, einmalige Produktion.
• Interne Schwellen. Prinzipien, Daten und Methoden legen wir vollständig offen; die konkrete Gate-Konfiguration, die Schwellen und die Sicherheitsdetails bleiben vorerst intern.

Fazit: KI-Entwicklung braucht Qualitätsingenieure

Six Sigma war eine Disziplin, die unzuverlässige Maschinen zuverlässige Teile produzieren ließ. Die neueste Maschine auf dem Hallenboden ist ein KI-Code-Builder und sie braucht dieselbe Behandlung.

Prompt Engineering ist tot. KI-Entwicklung braucht Qualitätsingenieure.

Die freien Open-Core-Gates liegen hier: agentic-gates