Eine Dark Factory ist eine Fabrik, in der man das Licht ausschalten kann, weil niemand mehr auf dem Boden steht. In China werden so bereits Handys gebaut. In Folge 8 von Prompt & Proper nehmen Steffen Ochsenreither von der Post und ich das Konzept und legen es auf die Softwareentwicklung: Ziel rein, fertige Software raus, kein Mensch dazwischen.
Fünf Stufen bis zum Licht aus#
Es gibt inzwischen diverse Maturitätsmodelle dafür, wie man mit KI Code erzeugt. Ich fasse sie in fünf Stufen zusammen.
Stufe 1 ist Autocomplete. Die KI ergänzt, der Mensch sitzt am Keyboard und tippt. Stufe 2 ist der Coding-Assistent. Du sagst “schreib mir zu dieser Methode einen Test”, und er schreibt den Test. Auf Stufe 3 wird es interessant, weil du mehrere Agenten hast. Einer unterstützt beim Entwickeln, ein zweiter macht Quality Assurance. Lose gekoppelt, Human in the Loop.
Stufe 4 sind ganze Workflows. Wir haben zum Beispiel einen Workflow implementiert, der die Requirements verfeinert, gleich die Testspezifikationen schreibt und einzelne Coding-Tasks übernimmt. Mehrere Agenten, zusammengehängt, aber nicht end to end: Der Mensch steht drin und reviewt, was produziert wird. Die Firmen, die heute bezüglich AI-Coding am weitesten sind, stehen auf dieser Stufe.
Stufe 5 ist der heilige Gral. Ich sage dem System, ich hätte gerne ein CRM-System, und hinten ploppt ein CRM-System raus. Das ist die Dark Factory.
Wo die Analogie bricht#
Steffen hat sofort den wunden Punkt getroffen. In der industriellen Fertigung sind Dark Factories stark repetitive Prozesse. Immer das Gleiche, und genau deshalb funktioniert es.
„Da prüft keiner mehr, ist die Adresse, die gelesen wird auf dem Brief oder auf der Sendung, ist die korrekt."
Im Logistikumfeld der Post läuft das längst so. Die Sortieranlagen haben Fehlerraten, die werden beobachtet, und der Grossteil der Sendungen wandert einfach durch. Anders wäre es gar nicht mehr möglich. Insofern gibt es dort heute schon eine Dark Factory, bis zu einem gewissen Grad.
Die eigentliche Frage ist damit keine technische. Steffen stellt sie so: Bis wohin akzeptieren wir Fehler, und bis wohin akzeptieren wir eigenmächtige Entscheidungen der Maschine? Bei der Menge an Code, die ein agentisches System erzeugt, wird das zur Kernfrage. Wenn hinten ein CRM-System rausploppt, wie stellst du dann noch sicher, dass es tut, was es tun soll?
Der Unterschied zwischen Stufe 4 und Stufe 5#
Auf Stufe 4 bist du im Loop. Du überprüfst die Spezifikation, du überprüfst die Tests, die Designs, wenn du willst den Code, und du greifst korrigierend ein.
In der Dark Factory greifst du nicht mehr ein. Im Inneren spezifiziert das System selbst, schreibt sich selbst Tests, implementiert und loopt dann so lange, bis es die Spezifikation erfüllt, die es selber geschrieben hat. Zuzuschauen, wie es dabei Lösungen entwickelt, ist ziemlich spannend. Der Haken steckt im Nebensatz: Es prüft sich gegen sein eigenes Dokument.
Das Experiment: ein volles V-Modell auf ein Amiga-Spiel#
Ich habe das aufgesetzt, einmal rudimentär und einmal hardcore. Hardcore heisst: ein volles V-Modell, von den Requirements über Requirement Verification, System Design und System Verification bis runter zum Code. Also so, wie man sauber runterspezifiziert und dann implementiert.
Als Aufgabe kein CRM-System, sondern ein 2D-Kampfroboter-Spiel vom Amiga, das ich mag. Ziel: fertig genug für Steam. Das System hat mir ein paar Fragen gestellt, dann losgelegt, und am Ende stand tatsächlich ein Spiel da.
Würde ich für dieses Spiel Geld ausgeben? Nein.
Das ist der Punkt, an dem es ehrlich wird. Diese Modelle lösen eine Aufgabe so effizient wie möglich, oder anders gesagt:
„Diese verdammten LLMs sind extrem faul."
Was du bekommst, ist der Durchschnitt. Die Beine des Roboters bewegen sich komisch, der Boden bewegt sich komisch, und dann merkst du, dass da kein physikalisches Verständnis ist. Es kann auch gar keines haben. Dasselbe beim Geschmack. Warum ist das so dunkel? Dann macht er es heller, und es ist heller, aber nicht schöner.
Zu den Kosten: Das Ding hat über ein Wochenende rotiert und eine Milliarde Tokens verbraucht. Steffens Schätzung lag bei 500 bis 1000 Franken. Abgerechnet wurden 145 Dollar. Was dabei nicht vergessen werden darf: Diese Anbieter sind aktuell massiv subventioniert, die realen Kosten liegen höher.
Die Spezifikation schlägt den Code#
Steffen hat daraus die Konsequenz gezogen: Du arbeitest nur noch an zwei Endpunkten. Vorne die saubere Spezifikation, hinten die Kontrolle des Ergebnisses. Was dazwischen passiert, ist dir relativ egal.
„Umso schlechter mein Speck geschrieben wird, umso schlechter wird mein Code zwangsläufig, weil der Agent kann nur das interpretieren, was da drin steht."
Bei mir hat sich das ziemlich radikal gezeigt:
„Ich muss ehrlich sagen, ich habe den Code nicht angeschaut. Es interessiert mich gar nicht."
Das gilt aber nicht überall. Wir machen bei Zühlke viele kritische Entwicklungen, zum Beispiel Medizinalprodukte. Bei einem Gerät, das dir eine Flüssigkeit in den Körper pumpt, willst du, dass die Software der Pumpe zu 100 Prozent funktioniert. Solche Systeme werden weiterhin von Menschen gebaut, und dort lässt du bewusst keine KI ran. Der Settings-Dialog oder die Webseite daneben: generiert.
Wir gehen also in ein Zeitalter, in dem die Spezifikation wichtiger wird als der Code. Es wird Subsysteme geben, die ein Mensch implementiert hat, weil sie zu 100 Prozent funktionieren müssen. Alles andere wird generiert.
Steffen hat dazu einen zweiten Punkt, der operativ zählt. Wenn du die Spezifikation von einem Agenten schreiben lässt und die Tests vom selben Agenten, dann liegen die Tests sehr nah an der Spezifikation und laufen schön durch. Alles ausserhalb fällt durch.
Du lässt dein Kind das Diktat nicht schreiben und gleich selbst korrigieren.
Die Frage, welches Modell die Spezifikation prüft, ist dabei nicht egal. Ein Review-Agent auf demselben LLM fällt tendenziell weniger kritisch aus, ein anderes LLM wird ultra kritisch, was auch wieder eigene Probleme erzeugt. Belastbare Zahlen dazu gibt es meines Wissens noch nicht, das Thema ist bleeding edge.
Womit misst man eine Dark Factory?#
Steffen hat die Frage gestellt, und sie ist schwieriger, als sie klingt. Lines of Code? Sicher nicht. Anzahl Commits? Auch nicht. Wie viel Kaffee der Entwickler trinken kann, weil er nichts tun muss?
Was er als Kandidaten sieht: wie viele Loopbacks es braucht, bis ein akzeptables Ergebnis dasteht. Dazu Incident Rate und Overwrite Rate. Tokenkosten sind ein KPI, den man beobachtet, aber er würde ihn hinten anstellen.
Ich messe am Ende auf den Outcome. Das Ziel von Software ist, dass sich das Verhalten des Users ändert oder sein Problem gelöst ist und er dafür bezahlt. Das ist leider eine Lagging-Metrik, sie zeigt erst spät, ob du es richtig gemacht hast. Gute Leading Indicators dafür zu finden, halte ich für extrem schwierig.
Eine Erkenntnis aus dem Experiment, die ich aus der klassischen Entwicklung kenne: Wenn du einmal auf einem schlechten Niveau angekommen bist, geht es nur noch bergab. Aus einem schlechten Produkt noch etwas Gutes zu machen, gelingt kaum. Du musst sehr viel Energie investieren, nur um zu halten.
Gleicher Kontext, sonst 50 Inseln#
Steffens wichtigster Punkt zum Schluss betrifft die Wiederholbarkeit. In einer grösseren Organisation willst du Software, die nach denselben Standards geschrieben ist, damit sie hält und andere sie warten können.
„Sonst ist es 50x Vibe Coding."
Also nicht 50 kleine Dark Factories, die autark vor sich hin arbeiten, sondern 50, die im selben Kontext laufen. Gleiche Instruktionen dazu, wie Code auszusehen hat, gleiche Art, Specs zu schreiben, gleiche Art, ein Outcome zu erzeugen.
Der POC-Friedhof#
Dazu kommt der Teil, den ich bei vielen Firmen sehe und der auch bei den Dark Factories auftaucht: Proof of Concepts, die nie ankommen. Du willst die Software in Produktion bringen, und das heisst Monitoring, Logging und der ganze Betriebsteil.
Genau das habe ich in meiner Dark Factory nicht gesehen. Der Agent schaut nicht darauf. Dieses Verständnis, wie man Software in Produktion bringt und betreibt, ist das ganze DevOps-Movement, und es wird aktuell wieder völlig vergessen, weil man so schnell einen POC hinstellen kann. Die meisten enden auf dem Weg in die Produktion, oder sie fristen irgendwo ein Dasein als Zombie.
Das Fazit#
Steffens drei Punkte am Ende der Folge: Best Practices definieren, bevor du startest. Die Herausforderung ist nicht mehr, die Software zu schreiben, sondern mit einer guten Spezifikation zu starten. Früher hat die lange Entwicklungszeit diesen Engpass verdeckt, das ist vorbei.
Und dann die Frage, mit der die Folge endet:
„Muss ein Entwickler noch jede Zeile lesen oder reicht es, wenn er die Resultate kontrolliert?"
Wenn euch die Folge gefällt, abonniert Prompt & Proper auf Spotify, Apple Podcasts, Amazon Music oder YouTube und schreibt uns, mit welchem KI-Thema ihr gerade kämpft. Alle Folgen: promptandproper.ai.