AI Dark Factory Patterns

Im Dezember hat agentische Entwicklung mit gleich drei Modellen eine Schwelle erreicht, die sie so gut macht wie menschliche Entwicklung. Zumindest in meinem Fall. Und wie so viele habe ich das vorwiegend am Wochenende ausgenutzt und dabei weit mehr als eine Million Zeilen Code erzeugt, verteilt über mehrere Lösungen. Alles in Triple-A-Rating in SonarQube mit einer Testabdeckung von 80 Prozent. Ein Teil davon ist Open Source; den kann man sich also anschauen.

Das ist, für meine Verhältnisse, etwa 100 × so produktiv in Software, wie ich es normalerweise wäre.

Und wir kennen alle den Trick, wie man 100 × effizienter wird: Man lässt 99 Prozent der Arbeit weg, bzw. delegiert sie an eine andere Stelle, die sie macht. Also an die Agenten.

In meinem Fall ist das keineswegs eine Dark Factory, so weit bin ich fachlich und intellektuell noch nicht, aber immerhin auf dem Niveau des unten genannten Antipatterns des Mechanikers. Während Agenten die Software schreiben, bin ich nicht mehr der Dompteur, der ihnen zuschaut. Aber ich muss noch immerzu mit der Ölkanne um die Maschine herumlaufen, die die Software baut. Wie Charlie Chaplin in „Moderne Zeiten“.

Aber ein paar Pattern und Antipattern fallen auf dem Weg auf, und deshalb würde ich mich gerne darüber unterhalten.

Kurze Unterbrechung – KI, die im Unternehmen wirklich ankommt

Dark Factories

In der Fertigungsindustrie gibt es Fabriken, die vollständig im Dunkeln laufen. Keine Beleuchtung, keine Menschen auf dem Hallenboden – Roboter montieren, schweißen und prüfen rund um die Uhr. Das Licht fehlt, weil niemand da ist, der es braucht.

Eine Dark Factory in der Softwareentwicklung folgt demselben Prinzip. Agenten schreiben Code, führen Tests aus, prüfen Qualität, deployen und warten, ohne dass ein Mensch einzelne Schritte begleitet oder freigibt. Das System läuft, weil es so gebaut wurde, dass es läuft. Nicht weil jemand zuschaut.

Der Mensch ist nicht abwesend. Er hat vorher die Fabrik gebaut: die Regeln, nach denen produziert wird, die Qualitätsgrenzen, die nicht unterschritten werden dürfen, und die Mechanismen, die das System in Schuss halten. Seine Arbeit steckt in der Struktur, nicht im Betrieb.

Eine Dark Factory ist ein vollständiges Betriebssystem für organisationale Software – von der Requirements-Generierung über Implementierung, Deployment und Betrieb bis zur laufenden Wartung eines wachsenden Lösungsportfolios. Agenten übernehmen die Ausführung. Menschen definieren Ziele, Qualitätsgrenzen und die Regeln, nach denen das System sich selbst steuert.

Klingt gut. Aber.

Ich sagte es bereits: Die Dark Factory ist das Zielbild, nicht mein gegenwärtiger Zustand. In der Praxis bewegt man sich zunächst in Zwischenformen: Die Agenten schreiben, testen und verändern bereits eigenständig Software, aber an manchen Stellen hängt das System noch am Menschen.

Weil es immer mehr Spaß macht, erst mal ein Blick auf die Antipattern.

Antipattern: Zirkusdompteur

Ein Mensch, der in der Mitte des Agentensystems steht und jeden Agenten manuell dirigiert. Ohne ihn drehen sich die Agenten im Kreis – es gibt keine eigenständige Ziellogik, keine Fitness Functions, keine Selbststeuerung. Der Mensch ist nicht Aufseher, sondern für jede einzelne Bewegung in der Manage verantwortlich. Der die wilden Agenten keinen Moment aus den Augen verliert, weil er Angst hat, dass sie sonst das Publikum angreifen.

Das ist keine dunkle Factory, sondern ein manueller Prozess mit agentischer Fassade.

Der Zirkusdompteur ist eine Stufe unterhalb des Mechanikers: Wo der Mechaniker immerhin in ein laufendes System eingreift, läuft hier ohne ihn gar nichts. Die Lösung ist nicht Delegation, sondern System-Design – Agenten brauchen eine Struktur, die unabhängig vom Menschen funktioniert.

Antipattern: Der Mechaniker

Ein Operator, der zwar nicht mehr selbst agiert, aber sich um die Fehler selbst kümmert. Er behebt sie durch direkten Eingriff selbst, und verbessert nicht die Produktionsstraße. Das Ergebnis: Dieselbe Problemklasse kehrt immer wieder, wird immer wieder von Hand behandelt, und er hängt in einer Endlosschleife des Nachbesserns. Mit wachsender Systemkomplexität wird der Mechaniker genauso überlastet und unersetzlich.

Das Symptom ist Wiederkehr. Die Lösung ist nicht ein besserer Mechaniker, sondern die Abschaffung der Mechanikerrolle durch Automatisierung von Problemen.

Antipattern: Die Bullshit Factory

Das kennen wir aus Spec-Driven-Development: es gibt viele Requirements, viel agentische Arbeit, viel Code. Die Factory produziert Output in hohem Volumen, aber der Output ist weitgehend nicht einsetzbar, voller Widersprüche und Fehlannahmen. Bei menschlichen Entwickler:innen gibt es dieses Problem nicht, denn sie haben während der Arbeit diese Widersprüche entdeckt und korrigiert. Bei Coding-Agenten muss die Factory selbst dafür sorgen, und ihre Qualität entscheidet sich an der Fähigkeit zur Produktion von gutem und validiertem Code.

Die korrekte Sequenz ist: Validierung und Observability zuerst, Produktionsvolumen danach. Eine Fabrik, die guten Output nicht zuverlässig von schlechtem unterscheiden kann, kann nicht im Produktionsmaßstab betrieben werden.

Antipattern: Big Design Upfront als Source of Truth

Spezifikationen sind unverzichtbar – eine Dark Factory ohne sie läuft nicht an. Sie sind aber kein Beweis für Korrektheit, sondern ein Startpunkt.

In der Praxis sind Spezifikationen immer unvollständig, basieren auf Hypothesen, enthalten Fehlannahmen oder haben Teile schlicht nicht bedacht. Je detaillierter und selbstbewusster sie formuliert sind, desto gefährlicher wird es, wenn das System sie unhinterfragt umsetzt.

Die Source of Truth einer Dark Factory müssen deshalb programmatische Tests und Fitness Functions sein, nicht die Spezifikation. Sie erbringen den Beweis, dass funktionale und nicht-funktionale Anforderungen tatsächlich erfüllt werden. Die Spezifikation beschreibt die Absicht. Tests und Fitnessfunktionen prüfen die Wirklichkeit. Und wo beides auseinanderläuft, behält die Wirklichkeit recht.

Die Antipatterns benennen nicht nur, was schiefläuft. Sie zeigen auch ziemlich präzise, welche Strukturen fehlen. Kommen wir also zu den Patterns.

Pattern: Synthetic first, back testing later

Vor dem Launch einer Lösung existieren keine echten Nutzer. Synthetische Nutzer – Verhaltensmodelle der erwarteten Zielgruppe – werden befragt, um Requirements zu generieren und erste Szenarien zu validieren. Die Factory produziert auf dieser Grundlage.

Sobald die Lösung in Produktion ist, füllt echtes Nutzerverhalten und -feedback die Requirements-Pipeline. Synthetische Requirements bleiben für Grenzfälle und neue Szenarien erhalten, verlieren aber ihre Rolle als primärer Validierungsanker. Die Factory arbeitet ab diesem Punkt auf Basis beobachteter statt modellierter Realität.

Pattern: Quality Inversion

Oberhalb einer Schwelle aus Systemkomplexität und Produktionsgeschwindigkeit senken verpflichtende menschliche Freigabe-Gates die Ausgabequalität. Das System hat an diesen Punkten mehr relevantes Wissen kodifiziert als ein Mensch in der verfügbaren Überprüfungszeit aktivieren kann. Wenn er Mensch hier prüft ist das Ergebnis Rubber-Stamping oder Heuristiken, die weniger zuverlässig sind als die automatisierten Gates.

Quality Inversion ist ein Schwellenphänomen. Sie ist erkennbar daran, ob menschliche Einwände während der Freigabe die nachgelagerten Ergebnisse tatsächlich verbessern. Wo das nicht der Fall ist, ersetzt man Freigabe-Gates durch Fitness Functions.

Pattern: Narrator

Ein Agent, der komplexe Multi-Agenten-Systemaktivität in für Menschen lesbare Erklärungen übersetzt. Der Narrator berichtet nicht, er interpretiert und erklärt. Er entscheidet, was er hervorhebt, was er weglässt und welche Kausalzusammenhänge er explizit macht.

Wer mit Agenten arbeitet, kennt das Problem. Es passiert sehr viel, und es ist gar nicht mehr möglich, jedes Feature, jeden Commit, jeden Diff durchzulesen oder gar zu verstehen. Wenn man beurteilen will, was tatsächlich vorgefallen ist, bittet man den Agenten darum, das Ganze zusammenzufassen, zu erklären und den Impact zu bewerten. Der Narrator verlagert diese Aufgabe vom Pull des Menschen zum Push des Agenten. Die sinnvolle Erklärung für die Implementierung zu ist Teil der Aufgaben des Agenten.

Pattern: The Codification Imperative (Der Kodifizierungs-Imperativ)

Die eiserne Regel der Dark Factory: Kein manueller Fix ohne nachhaltige Korrektur. Jede Fehlerbehebung durch einen Menschen ist niemals nur eine Reparatur am Endprodukt (dem Code), sondern immer auch ein Auftrag, die Fabriklogik selbst zu erweitern.

Erkennt der Mensch – geleitet durch den Narrator – eine Lücke im System, darf er nicht einfach den Code patchen und weitergehen. Die gefundene Lösung muss kodifiziert werden: als neue Fitness Function, erweitertes Testszenario oder verbesserter Agenten. Man repariert nicht das Produkt, man aktualisiert den Bauplan der Maschine.

Dieser Mechanismus wirkt wie eine Immunsystem: Mit jedem systematisierten Fehler erhält die Factory neue Antikörper. Die Fehlerquelle wird permanent versiegelt, die Autonomie des Systems steigt und ein Zurückfallen hinter das einmal erreichte Qualitätsniveau wird vermieden.

Pattern: Self-Healing Production Line

Der Reifezustand einer Dark Factory nach mehreren Zyklen. Fitnessfunktionen laufen als Dauermonitore, nicht nur als Abschlussgates. Erkannte Verletzungen lösen Correction Agents aus, ohne auf menschlichen Auftrag zu warten. Ressourcen wie Rechenkapazität, Agenten-Parallelität, Infrastrukturkosten, sind bewusst verwaltete Parameter.

Die Menschen schreiben keine Reviews. Sie schreiben die Regeln, nach denen das System sich selbst bewertet und korrigiert.

Pattern: Full-Cycle Deployment

Deployment ist nicht der Schritt nach der Factory – es ist Teil der Factory. Qualitätsprüfung, Sicherheitsanalyse und Laufzeitkonfiguration sind Bestandteil des Factory-Laufs. Die für least Privilege notwendigen Rechte der Laufzeitumgebung werden aus dem Code abgeleitet. Die Laufzeitumgebung skaliert mit Last und kostet bei Inaktivität nichts. Laufzeitfehler, die das System nicht auflösen kann, eskalieren an Wartungsagenten – und wenn diese es nicht korrigieren können, an den Menschen./p>

Was die Factory verlässt, ist nicht nur korrekt, es ist in Betrieb, gesichert und gewartet.

Pattern: Ambient Identity

Identität ist keine Funktion einzelner Anwendungen, sondern eine immer vorhandene Infrastrukturschicht. Jede Factory-produzierte Anwendung ist automatisch in das organisationale Identitätsmanagementsystem eingebunden. Und zwar nicht durch Konfiguration, sondern weil die Plattform diese Integration voraussetzt.

Zur Laufzeit handelt die Anwendung im Namen des authentifizierten Nutzers mit dessen Berechtigungen. Neue Lösungen können sofort auf alle Dienste und Daten der Organisation zugreifen, für die der Nutzer berechtigt ist. Identität ist kein Problem, das pro Anwendung gelöst wird – sie ist immer schon da.

Pattern: Living Portfolio

Ein wachsendes Portfolio verwaltet sich selbst. Jede neue Lösung wird beim Entstehen automatisch katalogisiert und dokumentiert. Wartungsagenten laufen dauerhaft gegen alle Einträge: Sicherheitslücken werden behoben, Dokumentation und Changelogs werden aus Code und Änderungshistorie generiert.

Das Portfolio ist keine Liste von Projekten, die gepflegt werden müssen. Es ist ein System, das sich selbst in Schuss hält – auch für Lösungen, die seit Monaten autonom laufen.

Pattern: Citizen Development as a Platform

Wenn eine Organisation eine Dark Factory betreibt, kann jeder Wissensträger Softwarelösungen direkt beauftragen. Der Auftraggeber beschreibt über einen Chat, was er braucht. Die Factory übernimmt Requirements, Implementierung, Deployment, Identitätsintegration und Portfolioaufnahme.

Die strategische Konsequenz: Die Grenze zwischen „leistbar“ und „zu aufwändig“ verschwindet für eine ganze Klasse von Lösungen. Abteilungen, die bisher auf generische Werkzeuge ausweichen mussten, erhalten maßgeschneiderte Lösungen in Tagen – betriebsbereit, gewartet, sicher.

Wo stehen wir in der Dark Factory?

Ich bin selbst noch nicht an diesem Punkt. Eher Mechaniker als Architekt einer wirklich dunklen Fabrik. Aber genau in diesen Übergangszuständen wird sichtbar, worauf es ankommt: Nicht darauf, dass Agenten Code schreiben – denn das tun sie längst. Sondern darauf, dass aus vielen einzelnen Automatisierungen ein selbststeuerndes Produktionssystem wird.

Die entscheidende Frage ist deshalb nicht, ob agentische Entwicklung möglich ist, sondern ob wir Systeme bauen können, in denen menschliche Eingriffe nicht mehr den Betrieb tragen, sondern nur noch seine Regeln verbessern. Erst dann greift der Automation Ratchet wirklich.

Und erst dann ist die Dark Factory nicht mehr bloß eine Beschleunigung bestehender Softwarepraxis, sondern eine neue Betriebsform von Softwareentwicklung.