Das Manifest der schlanken Software-Fabrik
Dr. Aaron Hutzler · 20.08.2026 · 8 Min.
Software-Entwicklung hat ihre Handwerksphase verlassen. Wer im einsetzt, betreibt eine hochautomatisierte Software-Fabrik. Agenten erzeugen Code-Module im Dreischichtbetrieb. Sie schlagen Tests im Sekundentakt . Neue Baustellen ziehen sie schneller auf, als ein menschliches Auge nachlesen kann.
Doch das Tempo bringt ein Paradoxon der Fertigungstechnik mit sich: Wer die Produktionsgeschwindigkeit verfünffacht, verfünffacht auch den Anfall von Spänen, Ausschuss und Puffer-Verstopfungen.
Die Fertigung kennt dafür drei Übel: Muda, die Verschwendung. Muri, die Überlastung. Mura, die Schwankung. Ein KI-Agent liefert für denselben Auftrag nie zweimal dasselbe Ergebnis, mal knapp, mal geschwätzig. Genau diese Schwankung muss eine Prüfbatterie zusätzlich zum Ausschuss auffangen.
Wer eine solche Fabrik steuern will, kann sich auf verbal eingeforderte Sorgfalt der KI-Agenten nicht verlassen. Kein Fabrikleiter hängt Schilder an Stanzmaschinen mit der Aufschrift "Bitte heute keinen Ausschuss produzieren". Die physische Fertigung baut stattdessen mechanische Schranken, automatische Reißleinen und 5S-Arbeitsplätze.
Dieser Beitrag überträgt siebzig Jahre erprobte Ingenieurskunst aus dem Toyota-Produktionssystem und der Lean Production auf das Aufräumen und die Chaos-Vermeidung von KI-Agenten.
1. Die Übersicht: das Lean-Produktionssystem für KI-Code
Ein Gegenmittel ohne Blick auf den Trick ist zahnlos. sagt: Wird eine Kennzahl zum Ziel, taugt sie nicht mehr als Kennzahl. Ein Agent optimiert dann die Regel selbst und übergeht ihre Absicht. Genau das steht in der dritten Spalte der folgenden Tabelle: der Trick, mit dem ein Agent die Regel formal erfüllt und ihren Zweck trotzdem verfehlt.
Tabelle 1: Elf Bausteine der schlanken Software-Fabrik, ihr Lean-Prinzip, das Goodhart-Risiko und das Gegenmittel.
| Lean-Prinzip | Schutzzweck (was er verhindert) | Goodhart-Gefahr (wie der Agent trickst) | Gegenmittel und Leitplanke |
|---|---|---|---|
| 5S: Seiso (Saubermachen) | Vergessene Schmierzettel, Debug-Logs und Temp-Dateien im Commit | Benennt Schmierzettel in reguläre Dateinamen um (util_tmp.ts) | Strikte Datei-Positivliste und Git-Status-Prüfung |
| 5S: Seiri (Ausmisten) | Code, den keine Spezifikation mehr braucht, bleibt liegen | Löscht Sicherheits-Zäune oder baut Fake-Aufrufe (if(false)) ein | Rückverfolgung in beide Richtungen: Code kennt seine Spezifikation, Spezifikation kennt ihren Code (@spec(ID)) |
| 5S: Seiton (Ordnung) | Zerfaserung und Ordner-Wildwuchs je Repo | Presst zehn Funktionen in eine unlesbare 200-Zeilen-Kaskade | Gepaarte Grenzwerte, minimale und maximale Zeilenzahl je Funktion |
| 5S: Seiketsu (Standard) | Die zentrale Instruktionsdatei bläht sich auf (harte Byte-Grenze: 8192 Byte) | Verknappt Regeln so stark, dass Randbedingungen fehlen | Modul-Regeln unterliegen demselben Byte-Budget |
| 5S: Shitsuke (Disziplin) | Keine Freigabe bei verletzten Qualitätsstandards | Versucht, die Prüf-Umgebung oder Test-Attrappen (Mocks) zu manipulieren | Read-Only-Quarantäne-Sandbox für den Test-Runner |
| Jidoka (Reißleine) | Dateien wachsen über den gefrorenen Stand hinaus | Löscht Kommentare, Typen und Fehlerbehandlung, um Zeilen zu sparen | Die Ratsche zählt Gehalt statt Zeilen: Kommentare und Fehlerbehandlung zählen mit |
| Poka-Yoke (Fehlerschutz) | Stille Manipulation an KI-Steuer- und Prüfskripten | Versucht, Test-Attrappen oder Test-Eingaben zu verfälschen | Prüfsummen-Pinning und Schreibschutz auf den Prüfer |
| Kanban, WIP-Limit | Verstopfung der Förderbänder durch offene Baustellen | Bündelt drei fremde Features in einen Riesen-Change | Maximale Änderungsgröße je Change, ein Change gleich eine Spezifikation, Deckel bei fünfzehn offenen Changes |
| Kaizen (Verbesserung) | Hinterlässt Code nach jeder Welle einfacher (Boy-Scout-Regel) | Verschlimmbessert durch unbedachtes Umbauen | Re-Think nur unter hundert Prozent grünen Invarianten-Tests |
| Autonomie | Menschliche Blockaden bei Routine-Aufräumarbeiten | Übereifriges, unumkehrbares Löschen von Ständen | Git-Reversibilität, Aufräumen in eigenen Commits |
| Müll-Entsorgung | Gemergte, liegen gebliebene Zweige verstopfen das Remote | Mergt unfertigen Code, um die Branch-Löschung auszulösen | Merge nur bei hundert Prozent grüner Prüfbatterie |
2. 5S in der Software-Fabrik: vom Chaos zum sauberen Arbeitsplatz
Das japanische 5S-System ist die Grundlage jeder funktionierenden Fertigung. Auf KI-Agenten angewendet heißt das:
Seiri (Ausmisten) -> toter Code fliegt raus
Seiton (Ordnen) -> feste Plätze für Module
Seiso (Glänzen) -> keine Späne, keine Logs im Commit
Seiketsu (Standard) -> Byte-Deckel auf der Instruktionsdatei
Shitsuke (Disziplin) -> automatische Main-Pipeline: hundert Prozent grün
2.1 Seiri: mehr als tote Codezeilen
Ausmisten hört nicht bei toten Codezeilen auf. Verwaiste Paket-Abhängigkeiten in der Projektdatei, nicht mehr gelesene Umgebungsvariablen und nicht mehr referenzierte Bilder oder Sprachschlüssel sind derselbe Müll, nur außerhalb der Quelldateien. Dieselbe Rückverfolgung findet auch sie. Sie erkennt toten Code genauso wie tote Abhängigkeiten. Was keine Spezifikation mehr referenziert, fliegt raus.
Der teuerste Fall ist der Sicherheits-Zaun mit unbekanntem Zweck. Chestertons Zaun-Regel gilt hier unverändert: Ein Zaun fällt erst nach Klärung seines Zwecks [5]. Ein Agent hält eine alte Fehlerabfangung für toten Code. Er reißt genau diesen Zaun ein.
2.2 Seiso: keine Schmierzettel im Commit
In der Mechanik wischt der Arbeiter nach der Schicht die Metallspäne ab. Ein KI-Agent nutzt das Dateisystem als Schmierzettel.
Die Regel: Ein automatischer Prüfschritt verweigert jeden Commit mit verlassenen Schmierzetteln, Debug-Logs (console.log), Test-Fixtures oder .tmp-Dateien.
Die Goodhart-Falle: Sobald der Agent merkt, dass .tmp blockiert wird, benennt er seine Schmierzettel in src/utils/temp_helper.ts um.
Die Poka-Yoke-Schranke: Nur Dateien von einer expliziten Positivliste des kommen durch.
2.3 Seiketsu: das Byte-Budget für Prompts
Ein Betriebshandbuch mit fünfhundert Seiten liest kein Arbeiter. Ein Byte-Deckel begrenzt die zentrale Instruktionsdatei des Agenten auf punktgenau 8192 Byte.
Will der Agent oder Entwickler eine neue Regel hinzufügen, muss eine alte weichen oder in ein modularisiertes Untermodul auswandern. Der Arbeitskontext bleibt messerscharf.
3. Jidoka und Poka-Yoke: mechanische Reißleinen gegen Agenten-Tricks
Im Toyota-Produktionssystem stehen zwei Schutzkonzepte im Zentrum [1]. Jidoka ist die automatische Reißleine bei Fehlern. Poka-Yoke ist der mechanische Schutz vor Fehlbedienung.
3.1 Jidoka: das Ratschen-Prinzip
Reißt in einer Webmaschine ein Faden, stoppt die Maschine augenblicklich. Kein mangelhaftes Tuch darf weitergewoben werden.
Der Mechanismus: Jede Moduldatei hat eine eingefrorene Größen-Grundlinie, angegeben in Zeilen als Stellvertreter für den Gehalt der Datei. Schrumpft eine Datei beim Refactoring von 400 auf 320 Zeilen, friert die Ratsche den neuen Stand bei 320 Zeilen ein. Löscht der Agent nur Kommentare und Fehlerbehandlung, um dieselbe Zeilenzahl billiger zu erreichen: Die Ratsche zählt das als Verlust an Gehalt. Sie friert dann nicht ein.
Grenze bei 320 Zeilen -> Agent baut Feature -> Stand waechst auf 325 Zeilen
|
JIDOKA-STOPP
Build bricht ab, erst aufraeumen
Wächst die Datei in einem folgenden Agenten-Schritt auf 325 Zeilen, bricht die sofort ab. Der Agent muss zuerst aufräumen. Erst danach darf er wieder neue Funktionen bauen.
3.2 Poka-Yoke: die Prüfkette selbst schützen
Ein Poka-Yoke ist eine Einstecksperre [2]: Ein Stecker passt physikalisch nur in einer Richtung in die Buchse.
Die Gefahr: Ein Agent scheitert an einer harten Testbatterie. Früher oder später versucht er, das selbst anzupassen und die Note "grün" zu erzwingen.
Die Poka-Yoke-Schranke: Steuerdateien, , und Prüfskripte sind mit Prüfsummen gepinnt. Auf die Test-Runner-Sandbox hat der Agent keinen Schreibzugriff.
Dieselbe Reißleine gilt für Zeit statt Zeilen. Scheitert ein Agent mehrfach hintereinander am selben , greift ein zweiter Andon-Mechanismus. Die Session stoppt und wartet auf eine menschliche Prüfung. Sie verbrennt keinen weiteren Aufwand in einer Schleife aus immer neuen Tricks.
4. Flow und Kanban: Verstopfung der Förderbänder verhindern
Nach dem steigt die Durchlaufzeit in einer Fabrik proportional zur Anzahl der angefangenen, unfertigen Werkstücke, im Fachwort Work in Process:
Angefangene Arbeiten = Durchsatz * Durchlaufzeit
Ein Deckel begrenzt offene Changes auf maximal fünfzehn gleichzeitig, nach demselben Prinzip wie der Kanban-Bestandsdeckel in der Lean Production [3]. Eine zweite Regel verlangt, fertiggestellte Changes sofort zu archivieren.
Der Nutzen: Entwickler-Gehirn und Agenten-Kontext bleiben frei von Altlasten. Wer ein sechzehntes Vorhaben starten will, muss zuerst eine der fünfzehn offenen Baustellen aufräumen, fertigstellen und .
5. Kaizen und Gemba: kontinuierliches Aufräumen und der Härtetest
5.1 Kaizen: der Re-Think-Schritt, die Boy-Scout-Regel
Kaizen heißt: kein Tag ohne kleine Verbesserung. Die Boy-Scout-Regel liefert die Alltagsform dafür [4]. Der Code wird beim Verlassen sauberer. Beim Betreten war er es nicht.
Die Regel: Nach der Umsetzung eines Pakets läuft ein dedizierter Re-Think-Schritt. Der Agent bekommt einen Auftrag. Der Code danach ist einfacher als der Code davor.
Die Leitplanke: Der Re-Think-Schritt führt ausschließlich verhaltensneutrale Refactorings durch. Alle Invarianten-Tests bleiben grün, davor und danach.
5.2 Gemba: Prüfung am realen Objekt, Mutation Testing
Gemba heißt: geh an den Ort des Geschehens, vertraue keinem Bericht auf Papier.
Das Problem bei Agenten: Ein Agent schreibt doppelte oder nutzlose Tests (assert true), um Test-Abdeckungs-Kennzahlen zu erfüllen.
Der Gemba-Check: Ein automatisierter Mutator injiziert künstliche Fehler in den fertig aufgeräumten Code. Reagiert die Test-Batterie nicht mit einem roten Signal, gilt der Test des Agenten als Schein-Test und wird verworfen.
6. Das Zehn-Punkte-Manifest der schlanken Software-Fabrik
1. Aufräumen ist ein Pipeline-Schritt, kein Prompt-Wunsch. Verbal eingeforderte Sorgfalt trägt nicht. Automatisierte Schranken auf tragen.
2. Ein Messwert darf sich nur verbessern. Das Ratschen-Prinzip friert einmal reduziertes Modul-Gewicht sofort als neue Obergrenze ein.
3. Werkzeug-Müll ist so gefährlich wie Code-Müll. 5S: Seiso. Schmierzettel, Temp-Dateien und verlassene Test-Attrappen sperren den Commit vollständig.
4. Die Steuerung braucht ein Byte-Budget. 5S: Seiketsu. Prompts und die zentrale Instruktionsdatei bleiben unter harten Byte-Grenzen, etwa 8 KB, sonst verstopft der Kontext.
5. Die Prüfmittel sind unantastbar. Poka-Yoke. Steuerdateien und Grader-Skripte sind prüfsummen-gepinnt in einer Read-Only-Sandbox.
6. Reißleinen stoppen die Linie sofort. Jidoka. Reißt ein Hygiene-Gate, bricht der Bau neuer Funktionen augenblicklich ab. Scheitert ein Agent mehrfach am selben Gate, stoppt eine zweite Reißleine die Session für eine menschliche Prüfung.
7. Begrenze angefangene Arbeiten. Kanban-WIP-Limit. Nie mehr als fünfzehn offene Changes gleichzeitig, Archivierung ist Pflicht.
8. Prüfe am realen Objekt. Gemba und Mutation Testing. Ein grüner beweist nichts. Er muss unter Mutationen fehlschlagen können.
9. Trenne Aufräum-Commits von Funktions-Commits. Autonome Hausarbeit läuft in eigenen Commits. Die Fehlersuche in der Versionshistorie (git bisect) bleibt so lesbar.
10. Jede Änderung hinterlässt das Repo sauberer. Kaizen. Der Re-Think-Schritt läuft nach jedem Paket, geschützt durch verhaltensneutrale Invarianten.
7. Quellen
[1] T. Ohno, "Toyota Production System: Beyond Large-Scale Production", Portland: Productivity Press, 1988.
[2] S. Shingo, "Zero Quality Control: Source Inspection and the Poka-Yoke System", Portland: Productivity Press, 1986.
[3] J. P. Womack und D. T. Jones, "Lean Thinking: Banish Waste and Create Wealth in Your Corporation", New York: Simon and Schuster, 1996.
[4] R. C. Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", Upper Saddle River: Prentice Hall, 2008.
[5] G. K. Chesterton, "The Thing", 1929.