Dark Factory gescheitert: Was Cole Medin über autonome KI-Softwarefabriken lernte

Autonome Agenten, die Software von der Epic bis zur Produktion durchlaufen, ohne dass ein Mensch den Code anfasst: Cole Medin hat genau dieses System als öffentliches Experiment gebaut, die KI-Dark-Factory nach Dan Shapiros Fünf-Stufen-Modell. Im neuen Video zieht er eine ungewöhnlich klare Bilanz: Die Dark Factory funktioniert nicht, und zwar nicht wegen schwacher Modelle. Sein Argument reicht tiefer: Auch mit perfekten Sprachmodellen bliebe der Engpass der menschlichen Absicht, denn niemand kommuniziert exakt, was er will, und ein Modell, das besser baut, wird damit nicht automatisch besser darin, Absichten zu lesen. Was Medin stattdessen betreibt, ist keine Rückkehr zum Handschalter-Modus, sondern eine KI-Softwarefabrik, die hunderte Ausführungen pro Woche schafft: Planung außen, Release als Einheit, Issue hinein, Pull Request heraus, Validierung und Review im Kernloop, ein Manager-Agent als Überwachung. Dieser Beitrag rekonstruiert beide Seiten aus dem Video und den Primärquellen: warum Stufe 5 scheitert und welches System nach Medins Worten tatsächlich trägt.

Das Fundament liefert Dan Shapiro mit seinem Blogpost über die fünf Stufen KI-unterstützter Programmierung, modelliert nach den Fahrstufen des autonomen Fahrens. Simon Willison hat den Text Anfang 2026 vorgestellt und Shapiros Kernsatz festgehalten: Auf Stufe 5 ist es kein Fahrzeug mehr, sondern eine Blackbox, die Specs in Software verwandelt, dunkel, weil dort Menschen weder gebraucht noch willkommen sind. Die meisten arbeiten laut Medin im Alltag auf Stufe drei, vielleicht Stufe vier; Stufe fünf ist die Dark Factory ohne Lenkrad: Man liefert das Ziel, eine Epic oder Release-Vision, der Rest ist Sache der Fabrik. Medins ursprünglicher Aufbau folgte genau dieser Vorstellung und lief als öffentliches Experiment, mit Videos und Livestreams, vorwiegend zu dem Teil, der von Hand gebaut werden muss: dem Harness, dem Gerüst aus Prozessen, Werkzeugen und Regeln, das den Agenten vor dem Lauf definiert. Der Betrieb selbst sei langweilig gewesen, erzählt er, man wartet nur darauf, wie die Agenten ihre Aufgaben abarbeiten.

Der zentrale Fehler liegt nach Medin in einem Engpass, den Modellqualität kaum auflöst: Sprachmodelle werden von Generation zu Generation besser im Bauen von Software, aber nicht messbar besser im Verstehen dessen, was Menschen eigentlich wollen. Eine Fabrik, die mit einem einzigen Hochlevel-Dokument beliefert wird, muss die Lücken zwischen Wunsch und Wort selbst füllen, und genau dort entstehen die Fehler. Menschen kommunizieren niemals perfekt, welche Features sie brauchen, wie ihr Codebestand gepflegt werden soll, welche Randfälle zählen. Daraus folgt Medins Kernsatz: So mächtig die Modelle auch werden, sie werden nie einfach unsere Gedanken lesen können. Im Raum steht die Gegenposition, zukünftige Modelle könnten eigene Absichten entwickeln, die unsere übertreffen, womit sich die Softwareentwicklung vollständig abgeben ließe; Medin kauft das nicht. Er hält den Menschen dauerhaft im Fahrersitz, weil Kundenwünsche, Geschäftskontext und Codebestandspflege Wissen sind, das der Mensch im Team trägt. Wer den Bestand wirklich versteht, ist auch der, der ihn weiterentwickeln kann, agentengetrieben oder nicht.

Das zweite Argument stammt aus der Praxis anderer: Medin verweist auf einen viel zitierten Vortrag von Dex Horthy über das Scheitern von Softwarefabriken, dessen Hauptargument die Wartbarkeit des Codebestands ist. Agenten pflegen Codebestände auf eine eigentümliche Art: Sie verzweigen sich, sie lassen Strukturen wachsen, die ein Mensch später kaum durchdringt. Horthy hat nach Medins Bericht dieselbe Reise gemacht: zuerst eine Dark Factory aufgebaut, dann zurückgerüstet und mehr Mensch-in-der-Schleife eingebaut, bis das System real tragbar war. Die Richtung stimmt in zwei unabhängigen Experimenten überein: Die vollständige Entfernung des Menschen bricht nicht am Modell, sondern an der Absicht und am Codebestand. Beides bleibt Arbeit für Menschen, unabhängig davon, wie gut das nächste Modell benchmarket.

Der Gegenentwurf heißt KI-Softwarefabrik und hebt sich an einer entscheidenden Stelle ab: im Umfang des Arbeitspakets, das die Fabrik autonom abarbeitet. Die Dark Factory erhält ein Hochlevel-Dokument für eine gesamte Anwendung, darf Tickets aufteilen, Absichten ergänzen und bis zur Produktion durchlaufen. Die Softwarefabrik erhält dagegen individuelle Releases: Der Mensch plant mit seinem eigenen Prozess, produziert ein PRD oder ein Architekturdokument und liefert dieses als Eingabe; die Tickets teilt die Fabrik in diesem Rahmen auf, und der Mensch prüft genau diese Aufteilung, statt sie dem Modell zu überlassen. Der Kernloop bleibt gegenüber der Dark Factory unverändert: Ein GitHub-Issue ist die Eingabe, der Pull Request ist die Ausgabe, und daran arbeitet sich die Fabrik ab, parallel über mehrere Labs, denen ein Abhängigkeitsmapping vorausgeht. Der Unterschied liegt laut Medin nicht in der Schleife, sondern in allem, was davor und danach passiert, und genau dort sitzt der Mensch.

In der Schleife selbst zeigt sich, wie viel Engineering in Zuverlässigkeit gesteckt wurde. Zu Beginn jeder Runde wählt die Fabrik ein Issue aus und setzt ein Claim-Label, damit parallele Labs nicht dasselbe Ticket anfassen. Dann fällt eine Vorabentscheidung: Ist das Ticket simpel und verdient einen schnelleren Build-Workflow, oder komplex genug für Iterationsphasen? Danach laufen Build, Validierung und Code-Review getrennt: Die Validierung erhält Werkzeuge, um die Anwendung tatsächlich wie ein Nutzer zu bedienen, Klicks, Texteingaben, Szenarien, und ersetzt damit einen Teil der manuellen Tests. Der Review prüft danach, ob der Code einfach, wartbar und korrekt implementiert ist, eine Analyse, die erst Sinn ergibt, wenn die App nachweislich läuft. Scheitert eine Phase, geht das Ticket mit begrenzten Wiederholungsversuchen an den Implementierungsworkflow zurück, damit die Fabrik nicht in einer Endlosschleife versinkt. Gemergt wird nur, wenn CI grün ist und der geprüfte Code durchkommt, immer auf einen Branch, der ins Staging führt. Am Rand sitzen Schutzmaßnahmen: Kernkontext-Dateien wie eine mission.md oder engineering.md dokumentieren außerhalb des Umfangs liegende Wünsche und Leitlinien und stehen laut Review-Regel unter Schutz, die Factory darf ihre eigenen Berechtigungen und ihr Verhalten nicht umschreiben.

Neu hinzugekommen ist eine Überwachungsebene: Ein Manager-Agent läuft regelmäßig im Zwei- bis Drei-Stunden-Takt und blickt über alle Runden hinweg, weil die einzelnen Labs untereinander nicht erfahren, wenn sich Abhängigkeiten ändern oder ein Pull Request endgültig blockiert ist. Sitzt ein Agent nach den maximalen Wiederholungsversuchen fest, richtet der Manager die Tickets neu aus oder übernimmt einen Workflow und beendet ihn; meldet er echten Eingriffsbedarf, wird Medin benachrichtigt, der sich dabei oft von einem Claude-Code-Agenten als zweitem Gehirn unterstützen lässt. Für die Endprüfung im Staging baut er bewusst Mensch ein: Features werden selbst getestet, Feedback geht als neue Issues zurück ins Repository, die Fabrik arbeitet sie ab wie die ursprüngliche Aufteilung der Epic; vier oder fünf Feedback-Issues lassen sich so in einer Runde abarbeiten und erneut testen. Erst nach dieser Runde geht es in die Produktion. Genau hier verschwand bei der Dark Factory der Schritt, der Realität trägt: Sie lief direkt in die Produktion. Tokenökonomie ist zudem ein Designprinzip: Verschiedene Knoten des Workflows laufen mit unterschiedlichen Modellen und Anbietern, für die Planung die großen Argumentierer wie Opus 5.5 oder GPT-6 Astra, für Ticket-Routing und einfache Aufgaben kleinere Modelle wie Sonnet 5.5. Das Ergebnis laut Medin: hunderte Factory-Runs pro Woche, ohne die Ratelimits zu erreichen.

Medin spricht als Praktiker mit eigenem Experiment und hunderten Stunden Bau- und Testzeit, aber der Beitrag liefert keine Fehlerquoten, keine Merge-Raten und keinen direkten Vergleich zwischen Dark-Factory- und Softwarefabrik-Betrieb; die Angabe hunderte Runs pro Woche bleibt seine eigene Messung, eine unabhängige Reproduktion fehlt. Die Passage zum Port-Katalog ist gesponsert und im Video als solche markiert, sie adressiert die Organisationsebene für Teams mit hunderten Services und Agenten-Pull-Requests, ändert aber nichts an der Argumentation zu Absicht und Wartbarkeit. Die Botschaft für die Agenten-Praxis ist trotzdem handfest: Autonomie ist keine Stufenleiter zum Erklimmen, sondern eine Grenze zu setzen, und die Grenze sitzt dort, wo der Mensch unentbehrlich bleibt, bei der Absicht vor dem Lauf, bei der Wartbarkeit im lebenden Codebestand und bei der Endprüfung im Staging. Wer Fabriken bauen will, sollte diese drei Stellen einplanen, statt auf ein Modell zu warten, das Absichten errät. Nach Shapiros Taxonomie bleibt Stufe 5 ein Ziel ohne Fahrplan, Medins Softwarefabrik ist der aktuell tragbare Weg in diese Richtung.

Video: https://www.youtube.com/watch?v=GQatuTWSRqY
Dan Shapiro, Fünf-Stufen-Blogpost: https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/
Simon Willison zur Fünf-Stufen-Einordnung: https://simonwillison.net/2026/Jan/28/the-five-levels/

YouTube-Video 'My AI Dark Factory Dream Is Dead (Here's What Actually Works)' von Cole Medin, Kanal Cole Medin, Abruf 16.10.2026.
Dan Shapiro, 'The Five Levels: from Spicy Autocomplete to the Software Factory', Blog danshapiro.com, Januar 2026, Abruf 16.10.2026.
Simon Willison, 'The Five Levels: from Spicy Autocomplete to the Dark Factory', Weblog, Abruf 16.10.2026.
Dex Horthy, Vortrag zum Scheitern von Softwarefabriken, referenziert und zusammengefasst im Medin-Video, Abruf 16.10.2026.