Von der Manufaktur zur Fabrik: Wenn Software vom Band läuft

Bei uns zu Hause wird viel Lego gebaut. Max und ich sitzen meistens am Tisch, suchen Räder, diskutieren kurz über Farben, bauen ein Auto und schieben es über den Boden. Wenn eine Achse abfällt, ist meistens ziemlich klar, wo wir gerade Mist gebaut haben.

Das ist Handwerk (im spielerischen Sinne): schön langsam, alles überschaubar und direkt.

Zu Max’ großer Freude machen wir jetzt was Verrücktes: Wir setzen einen freundlichen humanoiden Roboter mit an den Tisch. Nicht so einen Industrieroboterarm, eher einen unermüdlichen Mitbauer aus einem Science-Fiction-Film. Er kann Teile suchen, Varianten ausprobieren und auch weiterbauen, wenn wir längst im Bett sind. Über Nacht entstehen einfach so zwanzig Autos auf dem Tisch, die wir am nächsten Morgen begutachten können.

Das klingt in der Theorie erstmal super. Aber der Roboter kennt unseren Tisch noch gar nicht. Er weiß noch nicht, wie wir die Steine sortiert haben. Er weiß nicht, welche Konstruktion beim Spielen hält, wann er fragen sollte und wann er nur den nächsten plausiblen Stein setzt. Wenn ich ihm jeden Handgriff einzeln erkläre, bin ich nicht schneller. Wenn ich ihn einfach machen lasse, bekomme ich morgens vielleicht zwanzig schrottige Konzeptautos, die Max’ Qualitätsansprüchen nicht im Geringsten genügen würden.

Hinzu kommt: Wenn der Roboter jetzt nur noch die passenden Steine sucht, verliere ich mit der Zeit meine Fähigkeit, im Lego-Haufen nach Mustern zu suchen und möglichst schnell bestimmte Teile zu finden. Ich werde selbst immer schlechter im Suchen und der Spaß am Bauen geht mit der Zeit auch flöten.

Stark vereinfacht fühlt sich agentische Softwareentwicklung für mich gerade genauso ein bisschen an.

Wo die Reise hingeht

Ich sehe das sowohl bei meinen kleinen Apps im Feierabendbetrieb als auch im Dayjob: Teams probieren Coding-Agents, automatisierte Workflows und neue Formen von Zusammenarbeit aus. Manchmal sitze ich daneben und assistiere, manchmal lasse ich einen Agenten eine längere Zeit autonom ein Feature bauen und schaue später, was daraus geworden ist.

Was mir in den letzten Monaten dabei am stärksten aufgefallen ist, ist gar nicht der irrwitzige Geschwindigkeitsgewinn beim erzeugen von Code. Der war ein Stück weit erwartbar. Interessanter sind jetzt die ganzen strukturellen Verschiebungen, die damit einhergehen.

Plötzlich ist nämlich gar nicht mehr so klar, wer hier eigentlich Verantwortung für das (Soft)Werk übernimmt. Wer hat dieses Feature eigentlich produziert? Der Coding-Agent? Der Review-Agent, der nichts mehr gefunden hat? Ich, der den Pull Request gemerged hat? Oder das Team, das die ganze Agenten-Pipeline von vorne bis hinten aufgesetzt hat? Governance verschwindet still und leise, weil sie nirgends mehr explizit hingehört.

Hinzu kommt der schrittweise Verlust der eigenen Fähigkeiten. Manuelle Routinen, die ich vor zwei Jahren im Schlaf gemacht habe, fühlen sich heute schon fast fremd an, weil sie mir abgenommen werden. Und die Reibung, die früher zum Lernen geführt hat, diese zähen Momente, in denen man Stunden mit irgendwelchen bekloppten Fehlern ringt, sind plötzlich weg. Schneller fertig, aber weniger durchdrungen und verstanden.

Robert Glaser hat das mal aus der Organisationsperspektive beobachtet und zugespitzt so formuliert: Wenn alle KI nutzen und ein Unternehmen trotzdem nichts dabei lernt, dann liegt das oft daran, dass die Loops, in denen das Lernen stattfindet, nicht geschlossen werden.

Ich glaube nicht, dass viele dieser Beobachtungen völlig neu sind. Sie tauchen nur jetzt gerade an einer für uns ungewohnten Stelle auf. Immer wenn eine Domäne vom Handwerk in eine stärker skalierte Produktionsebene rutscht, verschieben sich die Probleme: Tempo steigt, Output wächst, und plötzlich werden Dinge kritisch, die in einem Manufakturbetrieb fast nebenbei funktionierten. Verantwortung. Qualitätssteuerung. Wartung. Lernen. Wissensweitergabe.

Genau das passiert jetzt gerade mit Software. Bestimmte Teile des Entwickelns werden wiederholbarer, parallelisierbarer und messbarer. Genau für diese Teile könnte der Blick auf echte Produktionssysteme hilfreich sein quasi als historischer Warnzettel und weniger als Blueprint. Andere Branchen hatten ähnliche Schmerzen schon früher. Vielleicht muss Software ja an diesem Wendepunkt nicht jedes Rad neu erfinden.

Dicker Disclaimer vorweg: Ich habe wie immer keine Ahnung. Weder von Fabriken noch von Produktionssystemen. Ich habe nie an einem Band gestanden und ich habe leider nie in einem Automotive-Projekt mitgearbeitet. Aber genau deshalb frage ich mich, ob es nicht bereichernd wäre, einmal zu denen rüberzuschauen, die seit über hundert Jahren industrielle Produktion skalieren. Es muss ja nicht alles übertragbar sein. Aber wenn dort drüben über Jahrzehnte Antworten auf strukturelle Probleme entstanden sind, die wir gerade neu bekommen, lohnt der Blick vielleicht.

Was die Industrie auf dem Weg vom Handwerk zur Fabrik gelernt hat

Vor der Massenproduktion waren Autos teuer, knapp und stärker von handwerklicher Montage geprägt. Wagen entstanden in kleinen Betrieben, in denen erfahrene Mechaniker:innen ein Fahrgestell aufbockten und Schritt für Schritt fertigstellten. Jeder Wagen brauchte viel Zeit, Qualität hing stark daran, wie gut die Personen waren, die ihn bauten. Mehr Autos bauen bedeutete primär mehr Werkstätten, mehr Meister, mehr Lehrlinge. Erfahrung war der Engpass.

Henry Ford hat diese Manufakturen mit dem Fließband in Highland Park verändert. Die Bauzeit eines Model T sank von gut zwölf Stunden auf 93 Minuten, und der Preis fiel von 850 auf 260 Dollar. Das Auto wurde zur Massenware. Was dabei selten erzählt wird: Ford hatte ein heftiges Folgeproblem. Die Arbeit am Band wurde monoton, die Fluktuation der Arbeitskräfte im Werk explodierte. Ford reagierte darauf mit einer Verdopplung des Lohns, dem berühmten Fünf-Dollar-Tag. Die Ford-Geschichte zeigt also nicht nur den Durchbruch beim Durchsatz. Sie zeigt auch die Nebenwirkungen der Fließbandarbeit: monotone Tätigkeiten, hohe Fluktuation und ein System, in dem Qualität, Engpässe und Wissen anders organisiert werden mussten als im Werkstattbetrieb.

Die Herausforderungen, die in den Fabriken auftauchten, kamen nicht alle auf einmal. Auch die Antworten entstanden über Jahrzehnte. Die folgenden fünf Beispiele finde ich besonders passend, weil sich daraus vorsichtig Parallelen zur Softwareentwicklung ableiten lassen.

Das erste Problem: Defekte häuften sich unbemerkt. Wenn ein Fehler früh in der Linie entstand, wurde er oft erst viel später sichtbar. Reparatur war teurer als Vermeidung, und niemand wusste mehr sauber, wo der Fehler eigentlich entstanden war. Das Toyota Production System adressiert genau diese Art Problem unter anderem mit Jidoka und Andon: Arbeiter:innen können die Linie anhalten, wenn sie ein Problem sehen. Das klingt banal. Aber in einer Welt, in der Stillstand teuer ist, ist das eine kulturelle und ökonomische Ansage. Fehler an der Quelle abzufangen, kostet weniger, als sie durchlaufen zu lassen und am Ende einzusammeln.

Das zweite Problem: Qualität war eine Endkontrolle. Inspektoren prüften am Bandende, was am Anfang in den Prozess eingespeist worden war, eine teure und reaktive Logik. Walter Shewhart entwickelte 1924 bei den Bell Labs die Regelkarte und damit eine fundamentale Verschiebung. Qualität wurde schon am laufenden Prozess gemessen, nicht erst am fertigen Produkt. Man beobachtete den Prozess selbst und erkannte, wann er anfing, aus dem Ruder zu laufen. Später griffen Deming und andere dieses Denken in Qualitätsmanagement und kontinuierlicher Verbesserung auf. Six Sigma machte daraus in den Achtzigern bei Motorola eine eigene Methodik mit starkem Fokus auf Defektmessung und Prozessfähigkeit.

Das dritte Problem: Lokale Optimierungen brachten wenig, wenn der Engpass woanders lag. Wer den schnellsten Lackierprozess der Welt baut, produziert trotzdem nicht mehr Autos, wenn die Montage davor klemmt. Er produziert nur größere Warteschlangen. Eliyahu Goldratt hat 1984 in The Goal daraus die Theory of Constraints gebaut. Die Grundidee ist ziemlich einfach: In jeder Kette gibt es gerade eine Stelle, die den Gesamtdurchsatz begrenzt. Nicht zehn. Eine. Wenn pro Stunde nur zehn Motoren aus der Motorenstation kommen, bringt es wenig, wenn die Lackiererei hundert Karosserien schafft. Dann stehen nur noch mehr halbfertige Autos herum. Goldratts Punkt: Finde zuerst den Engpass, schütze ihn vor unnötiger Arbeit und verbessere genau diese Stelle. Alles andere fühlt sich produktiv an, macht das System aber nicht schneller.

Das vierte Problem: Je automatisierter die Linie, desto fragiler die Anlage. Wartung war lange entweder reaktiv (wenn etwas kaputtging) oder pauschal-präventiv (nach Zeitplan, oft verschwenderisch). Wer dafür zuständig war, war auch klar: die Instandhaltung, eine separate Abteilung mit eigenem Schichtplan. Seiichi Nakajima hat das in den 1970ern umgedreht. Total Productive Maintenance verschiebt einen Teil der Pflege in die Hände der Bediener:innen, die die Anlage täglich benutzen und ihre Geräusche, ihren Verschleiß, ihre Schwächen am besten kennen. Verfügbarkeit wird zur kollektiven Verantwortung.

Das fünfte Problem ist das unauffälligste, vermutlich aber das wichtigste: Eine Fabrik konnte hervorragend eingerichtet sein und trotzdem zu wenig lernen. Toyotas Antwort darauf steckt unter anderem in Kaizen, also kontinuierlicher Verbesserung, und Genchi Genbutsu: geh hin und sieh selbst. Verbesserung passiert dort, wo die Arbeit passiert, durch die Leute, die sie machen, in kleinen kontinuierlichen Schritten. Die Linie bekommt eingebaute Rückkopplungsschleifen. Eine Fabrik ist dann nicht nur eine Maschine, die Produkte produziert. Sie ist auch ein System, das sich selbst verbessert. Genau diese zweite Schicht ist es, die Robert in seinem Post anspricht, wenn er von ungeschlossenen Loops in KI-Teams schreibt.

Fünf Probleme, fünf Antworten und keine davon ist einfach nur ein Werkzeug. Es sind Reaktionen auf strukturelle Pathologien, die entstehen, wenn Produktion skaliert. Und genau deshalb lohnt sich die vorsichtige Übersetzung in Software.

Das ist nicht der erste Anlauf

Die Idee, industrielle Disziplinen auf Software anzuwenden, ist natürlich nicht neu. Software hat seit Jahrzehnten versucht, sich Begriffe und Methoden aus der Produktion zu picken. Mal hat das geholfen. Mal blieb es zu mechanisch für eine Arbeit, die zu großen Teilen aus Entwerfen, Prüfen und Verstehen besteht.

Six Sigma wurde ab Ende der 1990er auch auf Softwareprozesse angewendet. Das passte vor allem dort, wo Softwarearbeit viele ähnliche Fälle erzeugt: Fehler erfassen, Tests auswerten, Releases stabilisieren, Wartung verbessern, Support-Prozesse verstehen. Da kann man zählen, vergleichen und über Zeit sehen, ob ein Prozess besser wird.

Beim eigentlichen Entwerfen von Code wurde es schwieriger. Code ist eben kein Bauteil, das tausendmal identisch aus der Maschine fällt. Eine gute Lösung entsteht oft gerade dadurch, dass jemand überlegt, sich austauscht, anders schneidet, benennt, vereinfacht oder eine Abkürzung findet, die vorher noch nicht da war.

Lean Software Development war deshalb anschlussfähiger. Der Fokus richtete sich weniger auf Code als fertiges Teil und mehr darauf, wie Arbeit durchs System wandert: Arbeit sichtbar machen, Engpässe finden, parallele Arbeit begrenzen, Feedback verkürzen. Diese Ideen tauchen heute in Agile-, Kanban- und DevOps-Praktiken wieder auf.

Es gibt also eine langjährige Erfahrungsbasis und die zeigt ein deutliches Muster. Übertragungen, die sich auf Prozessfluss und Feedback konzentrierten, haben überlebt. Übertragungen, die Code zu stark wie ein standardisiertes Produkt behandelt haben, blieben sperrig.

Der Einwand bleibt also richtig: Software ist nicht plötzlich Fertigung, nur weil ein LLM beteiligt ist. Die alte Trennung war ziemlich brauchbar: Der Build-Prozess, Tests, Deployment und Release-Automatisierung liegen näher an Fertigung. Das eigentliche Programmieren liegt näher an Designarbeit. Man entwirft eine Lösung, prüft sie, verwirft Teile davon, benennt Dinge neu und findet manchmal einen Schnitt, den vorher niemand gesehen hat.

Design braucht Variabilität. Sonst entsteht nichts Neues. Fertigung braucht Stabilität. Sonst fällt das Produkt auseinander. Genau deshalb blieb die Übertragung industrieller Qualitätslogik auf Code immer schwierig. Sie passte dort gut, wo Arbeit wiederholbar wurde. Sie wurde schief, sobald sie Designarbeit so behandelte, als müsste dort jedes Mal dasselbe Teil aus derselben Maschine fallen.

Mit KI-Agenten, die Code generieren, ändert sich das jetzt fundamental.

Sie sitzen mitten in dieser Designarbeit, produzieren aber mit einem Tempo, das eher nach Fertigung aussieht: Varianten erzeugen, Tests ergänzen, Bugs und Sicherheitslücken stopfen, Reviews erstellen, Migrationen ausführen, Dokumentation aktualisieren. Genau dort wird die Fabrikmetapher interessant. Nicht weil Software jetzt Stahlblech wäre. Sondern weil Agenten Fertigungstempo in eine Arbeit bringen, die weiterhin kreative Designarbeit bedeutet.

Warum die Lage 2026 etwas anders ist

Wenn ein Agent in einer Pipeline nachts autonom irgendein Zeug produziert, ist das nicht mehr exakt das, was wir bisher unter Coden verstanden haben. Es ist auch keine klassische Fertigung. Es ist etwas dazwischen: nicht deterministisch genug für die Fabrik, aber schnell und skalierbar genug, um fabrikartige Probleme zu erzeugen.

Das macht die Sache auch so schwierig. LLMs erzeugen Variabilität aufgrund ihres Funktionsprinzips. Wenn man diese Variabilität komplett rausdreht, bleibt am Ende kein Agent übrig, sondern ein Compiler mit sehr umständlicher Benutzeroberfläche. Die offene Frage ist also nicht, wie wir jede Abweichung verhindern. Die Frage ist, wie wir gute Variabilität von schlechter unterscheiden können.

Für die schlechte Seite dieser Variabilität gibt es inzwischen erste Messpunkte. Studien rund um den SWE-bench zeigen: Nur weil ein AI-Agent den passenden Test grün bekommt, ist seine Lösung noch lange nicht gut genug für ein echtes Projekt. METRs Research Note zu SWE-bench Verified legt nahe, dass viele Lösungen zwar den Benchmark bestehen, aber in einem echten Review trotzdem nicht gemerged würden. Eine weitere Studie fragt direkt, ob solved issues in SWE-bench wirklich korrekt gelöst sind. SWE-PRBench schaut auf AI-gestützte Code-Reviews und kommt ebenfalls zu einem nüchternen Bild. SlopCodeBench untersucht, wie Codequalität über mehrere AI-Iterationen erodieren kann. Man kann über die Repräsentativität solcher Studien streiten. SWE-bench ist nicht das echte Leben, und ein Snapshot von heute sagt wenig über die Möglichkeiten von Review-Agenten in sechs Monaten. Darum geht es mir hier nicht. Der wichtigere Befund ist: Defekte, Erosion und Drift werden messbar. Aber in der täglichen Anwendung, die ich so beobachte, werden sie (noch) nicht konsequent als Prozesssignale behandelt.

Hinzu kommt eine neue Regulatorik. Die EU-Produkthaftungsrichtlinie 2024/2853 zählt Software künftig ausdrücklich als Produkt und muss bis zum 9. Dezember 2026 in nationales Recht umgesetzt werden. Ab dann gilt sie für Software-Produkte, die neu auf den Markt kommen oder erstmals genutzt werden. Das ist noch keine pauschale Prozesspflicht für jedes Softwareteam. Aber für bestimmte Softwareprodukte verschiebt es die Risikolage: Qualität, Änderungen und Risiken werden schwerer als bloße interne Engineering-Details zu behandeln sein. Industrieller Qualitätsanspruch wird dadurch nicht automatisch Pflicht. Er wird aber deutlich anschlussfähiger.

Das ist eine Konstellation, in der die Ansätze aus der Fabrik plötzlich anders klingen.

Was sich lohnt, einmal zu übertragen

Ich bin sicher nicht der Erste, dem das auffällt. Aber ich will mal fünf Stellen rauspicken, an denen die Herausforderungen aus der Industrie auch in der agentischen Softwareentwicklung plötzlich erstaunlich relevant werden können.

Engpassdenken auf die Pipeline anwenden. Goldratts Frage ist einfach: Wo ist heute der Engpass? Für agentische Workflows und Team-Topologien sehe ich bisher kaum etablierte Praktiken dafür. Ist es der Coding-Agent, der Review-Agent, die Ende-zu-Ende-Tests, das menschliche Approval, die Discovery-Phase? Optimiert wird oft, was am sichtbarsten ist: der Code erzeugende Teil, weil dort gerade auch die größte Aufmerksamkeit herrscht. Ob das tatsächlich der Engpass ist, darf schon seit einiger Zeit bezweifelt werden. Michael Nygard spielt genau das mit der Theory of Constraints durch: Wenn AI nur die Coding-Station beschleunigt, steigt nicht automatisch der Gesamtdurchsatz. Oft wächst erstmal nur der Stapel unfertiger Arbeit vor Review, CI, Tests und Deployment.

Prozess statt Produkt messen. Die Lehre aus früheren Software-Six-Sigma-Versuchen ist: Prozesskontrolle auf den Code selbst anzuwenden, bleibt schwierig. Prozesskontrolle auf das System anzuwenden, das Code ausliefert, funktioniert deutlich besser. Für einen Agent-Harness bedeutet das im Kleinen schon heute: nach dem Editieren linten, formatieren, Unit-Tests laufen lassen. Für AI-Pipelines im Großen bedeutet das: Defektklassen definieren, kontinuierlich messen und eskalieren, wenn ein Prozess driftet. Doch nicht jede Abweichung ist automatisch ein Defekt. Zwei Agenten können verschiedene Lösungen bauen, und beide können gültig sein. Interessant wird es dort, wo Variabilität nicht mehr neue Optionen erzeugt, sondern Intention verliert: Konventionen kippen, Architekturgrenzen verschwimmen, derselbe Fehler kommt in der dritten Iteration wieder. SlopCodeBench-artige Benchmarks könnten hier ein guter Startpunkt sein.

Andon-Äquivalente bauen. Ein autonom laufender Verbund aus Agents, der acht Stunden durchackert und am Morgen entweder etwas Funktionierendes oder sehr teure Schrotthaufen hinterlässt, ist genau die Art Logik, die Toyota überwinden wollte: Fehler nicht bis ans Ende durchlaufen lassen. Dafür braucht es aber nicht zwingend permanent einen Menschen im Getriebe, und wie mein Kollege Michael festgestellt hat, wäre der Mensch als reine Endkontrolle ohnehin keine besonders verlässliche Instanz. Es braucht aber etwas im Loop, das die Pipeline anhalten kann und neu kalibriert, wenn die Defektrate steigt oder ein Review-Agent dasselbe Problem zum dritten Mal zurückgibt.

Die Stop-Taste ist dabei nicht der komplizierte Teil, eher wann sie gedrückt wird. In der Fabrik fragt man: Weicht das Teil von der Spezifikation ab? Bei einem Coding-Agenten reicht das nicht. Da muss man eher fragen: Hat der Agent die Absicht hinter der Spec noch verstanden? Bewegt sich die Lösung noch im definierten Lösungsraum? Oder produziert sie nur noch plausibel aussehende Arbeit, die später ein Mensch teuer entwirren muss?

Verantwortung für die Anlage selbst. TPM stellt die unbequeme Frage, wer eigentlich für die Verfügbarkeit der Produktion zuständig ist. In Software übersetzt heißt das: Wer kümmert sich um Modell-Drift, Prompt-Degradation, Eval-Veralterung, Harness-Hardening, Tool-Konfiguration? Heute ist diese Verantwortung oft diffus. Nutzer:innen melden Probleme zurück, Plattformteams betreiben Teile der Infrastruktur, einzelne Enthusiast:innen pflegen Skills ihrer Coding-Agents. Das kann eine Weile funktionieren. Für ein Produktionssystem ist es aber zu lose.

Cognitive und Intent Debt nicht unter den Tisch fallen lassen. Automatisierung bringt Menschen in eine paradoxe Lage: Je mehr ein System selbst erledigt, desto seltener nutzen Menschen bestimmte Fähigkeiten. Gleichzeitig werden genau diese Fähigkeiten im Störfall besonders wichtig. Je seltener solche Störfälle auftreten, desto schwerer bleibt es, diese Fähigkeiten wachzuhalten. Das gilt für die Produktion von Autos genauso wie für Software.

Peter Naur hat das Problem so beschrieben: Software ist nicht nur Quellcode, sondern vor allem eine Theorie in den Köpfen der Menschen, die daran arbeiten. Diese Theorie erklärt, wie die Welt auf das Programm abgebildet wird, warum bestimmte Entscheidungen getroffen wurden und wie man sicher weiterbauen kann.

Margaret-Anne Storey greift diesen Gedanken in ihrem TechDebt-Talk auf und beschreibt ein hilfreiches Dreieck: Technical Debt steckt im Code, Cognitive Debt in den Köpfen und Intent Debt entsteht dort, wo Begründungen, Ziele und Grenzen nicht festgehalten werden. Alle drei beeinflussen sich gegenseitig, und alle drei werden durch generative KI extrem beschleunigt, wenn man nicht aktiv gegensteuert.

Wenn immer mehr Code produziert wird und dabei das gemeinsame Verständnis über das, was gebaut wurde, und das, was gebaut werden sollte, zerbröselt, dann wird die Theorie dünner. An dem Punkt, an dem niemand mehr sauber erklären kann, warum ein System so gebaut wurde, wie es gebaut ist, wird es brandgefährlich. Wenn das Warum nirgendwo mehr landet, raten Mensch und Agent bei der nächsten Iteration nur noch weiter.

Das sind keine fünf voneinander unabhängigen Initiativen. Es sind Rückkopplungen desselben Produktionssystems. Defektklassen machen Andon erst sinnvoll. Engpassdenken verhindert, dass man Generatoren optimiert, während Review oder Integration längst dicht sind. Cognitive Debt zeigt, ob das Team noch versteht, was die Anlage baut. Intent Debt zeigt, ob Mensch und Agent noch wissen, warum sie es bauen. Fehlt eine dieser Schichten, läuft die Linie zwar weiter. Nur eben zunehmend blind. Und wenn Feedback, Kontrolle und Lernschleifen schon fehlen, ist es vermutlich keine besonders gute Idee, auch noch die Lichter auszuschalten.

Und wie merken wir, dass es etwas bringt?

Sobald man industrielle Disziplinen in Software einführen will, stellt sich die Frage, woran man erkennt, dass es sich lohnt. Denn der wunde Punkt ist klar: Falsch messen führt sehr wahrscheinlich auch zu miesem Management.

Das wird für AI-Pipelines zentral. Generierte Lines of Code, Pull Requests pro Tag oder Token-Durchsatz sind naheliegende Kennzahlen, aber schlechte Steuerungsgrößen. Sie zählen Aktivität, nicht Ergebnis. Wer nur Durchsatz erhöht, ohne Defekte, Nacharbeit und Wirkung zu messen, baut im Zweifel nur eine schnellere Slop-Maschine. Am Lego-Tisch wäre „Autos pro Nacht“ auch keine gute Metrik, wenn morgens alle dieselbe wackelige Radaufhängung haben. Herzlichen Glückwunsch, das Band läuft. Leider spuckt es nur Müll aus.

Es hilft, die Fragen sauber zu trennen. Auf Delivery-Ebene geht es um Deploy Frequency, Lead Time for Changes, Change Failure Rate und MTTR: Wie stabil liefert das System? Auf Flow- und Portfolio-Ebene zählen Cycle Time, Work Item Age und Cost of Delay: Woran sollten wir als Nächstes arbeiten? Auf Qualitätsebene geht es um Defektklassen, Nacharbeit, Escaped Defects oder Mutation-Test-Signale: Welche Fehler entstehen, wo entkommen sie dem Prozess, und wie viel Nacharbeit erzeugen sie? Und auf Organisationsebene geht es um Lern- und Risikosignale: Welche Fähigkeiten, Eskalationswege und Review-Routinen müssen erhalten bleiben?

Für die Fabrik ist daran entscheidend: Nicht jede Metrik beantwortet dieselbe Frage. Wer eine AI-Pipeline baut und nur Generator-Geschwindigkeit misst, optimiert auf der falschen Ebene. Ob die Industrie-Übertragung etwas taugt, zeigt sich nicht daran, ob mehr Code entsteht. Sondern daran, ob bessere Entscheidungen, weniger Nacharbeit und stabilere Lernzyklen entstehen.

Metriken sollten deshalb auch nicht zum Bewerten von Menschen verwendet werden. Sobald Teams glauben, dass bewertet wird, ob sie „genug AI“ nutzen, optimieren sie wahrscheinlich eher die Signale statt des Lernens.

Wo die Analogie hinkt, und wo nicht

Wir kommen noch mal zum Anfang zurück: Software ist kein Stahlblech. Eine Schraube ist eine Schraube, ein Code-Diff nicht reproduzierbar in demselben Sinn. Die Toleranzen sind andere und die Iteration ist billiger. Stimmt alles. Aber kein Grund, die Fabrikmetapher komplett wegzuwerfen. Es ist eher der Grund, sie nicht stumpf zu übernehmen.

Was die Industrie-Konzepte tragfähig macht, hängt nicht am Material, sondern an der Struktur des Skalierungsproblems. Defekte, die sich downstream auftürmen, gibt es überall, wo Schritte aufeinander folgen. Engpässe, die unbemerkt Verstopfung erzeugen, gibt es in den meisten Prozessen mit mehr als einer Station. Anlagen, die niemand wartet und pflegt, entstehen überall, wo keine klare Verantwortung definiert wird. Wissen, das verschwindet, wenn niemand mehr bestimmte Fähigkeiten einsetzt, gibt es in jeder Domäne, die starke Automatisierung erlebt. Das sind Folgen steigender Produktion. Mit einem Verbrennungsmotor haben sie wenig zu tun.

Wackelig wird es dann, wenn man die Begriffe übernimmt, aber die Struktur dahinter vergisst. Andon ist in einer Agenten-Pipeline keine Schnur. Es ist eine klare Stop-Bedingung: Hier läuft etwas aus dem Ruder, hier darf die Linie nicht einfach weiterproduzieren. Wartung heißt nicht, ab und zu Öl nachzufüllen. Sie heißt Harness, Evals, Prompts, Tools und Kontext kontinuierlich zu pflegen. Prozesskontrolle heißt nicht, alle Lösungen gleichzumachen. Sie heißt, erwünschte Variabilität von Drift zu unterscheiden.

Das ist Übersetzungsarbeit, keine Widerlegung. Ich glaube, Toyota hat Ford auch nicht kopiert. Toyota hat Fords Schwächen erkannt und etwas Neues gebaut, das Fords Logik weitergedacht hat. Genau diese Art von Übersetzung steht in Software meiner Meinung nach gerade an.

Und kurioserweise könnte die Industrie selbst bald vor einer ähnlichen Übersetzungsarbeit stehen. Wenn Embodied AI nicht nur plant, sondern physisch in Fabriken mitarbeitet, kommt Nicht-Determinismus ausgerechnet dorthin zurück, wo man ihn lange mühsam rausoptimiert hat. Mal sehen, ob bis dahin auch Fabriken noch etwas von der Softwareentwicklung lernen können.

Wahrscheinlich lohnt sich ein Blick über den Tellerrand

Ich bleibe bei dem, was ich am Anfang gesagt habe: Ich habe keinen Schimmer von Fabriken. Aber je länger ich beim Bauen meiner kleinen Apps und in Beratungsdiskussionen beobachte, wie sich Softwarearbeit verschiebt, desto schwerer fällt mir zu glauben, dass wir diese Fragen auf Dauer ignorieren können. Wenn Output billiger wird, werden Defekte, Engpässe, Wartung, Verantwortung und Wissensverlust teurer. Sehr viel teurer. Das ist eine strukturelle Verschiebung.

Tesla hat dieses Motiv prominent gemacht: Nicht nur das Auto ist das Produkt, sondern auch die Fabrik – The machine that builds the machine. Gleichzeitig zeigt Teslas Model-3-Hochlauf, dass die Analogie gefährlich wird, wenn man krasse Automatisierung mit Reife verwechselt. Genau deshalb ist der Fall interessant: Die Produktionsanlage ist nicht nur Mittel zum Zweck. Sie ist selbst ein gestaltbares, messbares und verbesserbares System. Aber mehr Automatisierung macht sie nicht automatisch besser. Ich glaube nicht, dass in der Industrie alle Antworten fertig herumliegen. Ich glaube aber, dass dort Fragen gestellt wurden, die wir in der Softwareentwicklung ab sofort ernster nehmen sollten.

Wenn ich das auf Software übertrage und mir vorstelle, wie eine KI-getriebene Software-Produktionsstraße in ein paar Monaten oder Jahren aussieht, dann frage ich mich: Wer baut diese Fabrik? Wer behandelt sie als Engineering-Problem? Und wer bringt dafür das Wissen mit, das in der Industrie längst da ist?

Und ein letzter Punkt, der mich besonders umtreibt: Beantwortet eine bessere Fabrik dann auch, was gebaut werden sollte? Wohl kaum. Sie ersetzt kein Produkturteil, keine Strategie und kein Verständnis für die Probleme von Menschen. Aber vielleicht wird genau das sogar sichtbarer, wenn die Software-Fabriken von morgen besser werden. Wenn Delivery billiger wird, merken Organisationen hoffentlich schneller, dass ihnen nicht Baukapazität fehlt, sondern belastbare Produktideen. Daniel Westheide hat das kürzlich sehr treffend formuliert: Die durch Automatisierung frei werdende Kapazität sollte nicht automatisch in noch mehr Features fließen, sondern in bessere Product Discovery. Features pro Zeiteinheit sind einfach keine sinnvolle Erfolgsmetrik, wenn niemand sauber geprüft hat, ob diese Features auch echte Nutzerbedürfnisse treffen.

Eine gute Software-Fabrik verhindert also hoffentlich nicht nur, dass wir falsche Dinge schneller, größer und komplexer bauen. Sie schafft im besten Fall auch Raum, früher zu merken, welche Dinge wir gar nicht erst bauen sollten.

Oder anders: Selbst der beste Roboter kann nicht beantworten, ob Max gerade wirklich zwanzig Autos braucht oder eigentlich eher einen Raumgleiter, eine Kettenraupe oder einfach jemanden, der mit ihm was baut und spielt.