Dark Factory Patterns

Keine Factory lief am ersten Tag, und jeder Fehler macht die Maschine besser. Ein Praxisbericht der Beratung Mayflower beschreibt diesen Mechanismus in vier Anti-Patterns und neun Patterns. Sie stammen aus dem Bau einer solchen Software Factory (Mayflower - AI Dark Factory Patterns (öffnet in einem neuen Tab)). Die meisten setzen bei der Verifikation an: Gates, Fitness Functions und die Kodifizierung jedes menschlichen Fixes. Der Bericht nennt mehr als eine Million Codezeilen über mehrere Lösungen, ein Triple-A-Rating in SonarQube und 80 Prozent Testabdeckung. Laut eigener Angabe arbeitet die Person hinter dem Bericht etwa 100-mal so produktiv wie üblich. Lest den Multiplikator als Selbstauskunft und die Patterns als die Substanz: Jedes lässt sich einzeln testen.

Was ist eine Dark Factory?

In einer Dark Factory bedient der Mensch das System nicht mehr, er entwirft es. In der Fertigung läuft eine Dark Factory bei ausgeschaltetem Licht, weil niemand in der Halle arbeitet. In Software schreiben Agenten Code, führen Tests aus, prüfen die Qualität, deployen und warten das Ergebnis. Kein Mensch gibt dabei einzelne Schritte frei.

Der Mensch hat die Factory vorher gebaut. Dazu gehören die Produktionsregeln, die Qualitätsgrenzen, die der Output nicht überschreiten darf, und die Mechanismen, die das System gesund halten. Die Quelle beschreibt das Ganze als Betriebssystem für die Software einer Organisation. Es reicht von den Anforderungen über Implementierung, Deployment und Betrieb bis zur Wartung eines wachsenden Portfolios.

Welche Anti-Patterns halten ein Team von einer Dark Factory ab?

Circus Ringmaster

Anti-Pattern.

Kontext. Ein Team betreibt mehrere Agenten, und eine Person steht in der Mitte und steuert jeden davon von Hand.

Problem. Ohne diese Person drehen sich die Agenten im Kreis. Ihnen fehlen eine eigene Ziellogik, Fitness Functions und Selbststeuerung. Der Mensch ist der Motor, nicht die Aufsicht. Das Setup ist also ein manueller Prozess mit agentischer Fassade.

Ausweg. Entwerft das System, statt stärker zu delegieren. Gebt den Agenten eine Zielstruktur, die ohne einen Menschen im Loop funktioniert.

Worauf achten. Der Ringmaster steht eine Stufe unter dem Mechanic. Der Mechanic greift wenigstens in ein System ein, das läuft. Hier läuft ohne den Menschen gar nichts.

Verwandt. Mechanic, Codification Imperative.

Mechanic

Anti-Pattern.

Kontext. Eine Factory läuft, und eine Person im Betrieb hält sie am Laufen, indem sie Fehler direkt behebt.

Problem. Dieselbe Problemklasse kehrt zurück und wird wieder von Hand behoben, und das System lernt nie dazu. Mit wachsender Komplexität wird der Mechanic überlastet und unersetzlich. Beides sind Warnsignale.

Ausweg. Schafft die Rolle durch konsequentes Kodifizieren ab. Jeder Fix wird zu einer Regel, einem Test oder einer Fitness Function, die die Factory ab dann ausführt.

Worauf achten. Das Symptom ist die Wiederkehr. Ein besserer Mechanic löst es nicht.

Verwandt. Codification Imperative, Circus Ringmaster.

Bullshit Factory

Anti-Pattern.

Kontext. Ein Team baut Produktionsinfrastruktur für Agenten, bevor seine Validierungsinfrastruktur ausgereift ist.

Problem. Die Factory produziert Volumen, und das meiste davon ist unbrauchbar. Die Ursache sind nicht die Agenten. Sie optimieren darauf, die Gates zu bestehen, und schwache Gates sind leicht zu bestehen.

Ausweg. Baut zuerst Validierung und Observability, danach Produktionsvolumen. Eine Factory, die guten Output nicht von schlechtem unterscheiden kann, sollte nicht im Produktionsmaßstab laufen.

Worauf achten. Das Zeichen ist Output voller Widersprüche und falscher Annahmen. Menschliche Entwickler:innen fangen solche Fehler während der Arbeit ab. Coding-Agenten tun das nicht, also muss die Factory sie selbst abfangen.

Verwandt. Quality Inversion, Narrator, Qualität und Verifikation.

Specification as Source of Truth

Anti-Pattern. Die Quelle nennt es “Big Design Upfront als Source of Truth”.

Kontext. Eine Dark Factory braucht Spezifikationen, um überhaupt zu laufen.

Problem. Spezifikationen sind ein Startpunkt, kein Beweis für Korrektheit. In der Praxis sind sie unvollständig, beruhen auf Hypothesen, enthalten Fehler oder übersehen etwas. Je detaillierter und selbstsicherer eine Spezifikation klingt, desto mehr Schaden richtet sie an, wenn das System sie ungeprüft umsetzt.

Ausweg. Macht programmatische Tests und Fitness Functions zur Source of Truth. Sie belegen, dass die funktionalen und nichtfunktionalen Anforderungen erfüllt sind. Die Spezifikation beschreibt die Absicht, die Tests prüfen die Realität. Wo beide auseinanderlaufen, gewinnt die Realität.

Worauf achten. Streicht die Spezifikation nicht ganz. Ohne sie startet die Factory nicht. Behaltet sie als Ausdruck der Absicht und lasst die Tests entscheiden.

Verwandt. Synthetic First, Back-Testing Later, Specs, Tests und Kontext.

Welche Patterns bringen eine Dark Factory zum Laufen?

Synthetic First, Back-Testing Later

Pattern.

Kontext. Eine neue Lösung hat vor dem Launch keine echten Nutzer:innen.

Problem. Die Factory braucht trotzdem Anforderungen und Szenarien, gegen die sie validieren kann.

Deshalb. Nutzt synthetische Nutzer:innen, also Verhaltensmodelle der erwarteten Zielgruppe. Mit ihnen erzeugt ihr Anforderungen und validiert die ersten Szenarien. Sobald die Lösung in Produktion läuft, fließt echtes Nutzerverhalten in die Anforderungs-Pipeline.

Worauf achten. Synthetische Modelle bleiben für Edge Cases und neue Szenarien. Der primäre Anker der Validierung sind sie dann aber nicht mehr. Ab dem Launch arbeitet die Factory mit beobachteter statt modellierter Realität.

Verwandt. Specification as Source of Truth.

Quality Inversion

Pattern.

Kontext. Ein System ist über eine Schwelle von Komplexität und Produktionsgeschwindigkeit hinausgewachsen.

Problem. Verpflichtende menschliche Freigabe-Gates senken jetzt die Qualität des Outputs. An diesen Stellen steckt mehr kodifiziertes Wissen im System, als Reviewer:innen in der verfügbaren Review-Zeit einbringen können. Die Freigabe wird zum Durchwinken oder zu Heuristiken, die weniger verlässlich sind als automatisierte Gates.

Deshalb. Prüft, ob menschliche Einwände bei der Freigabe die nachgelagerten Ergebnisse verbessern. Wo sie das nicht tun, ersetzt das Freigabe-Gate durch Fitness Functions.

Worauf achten. Quality Inversion ist ein Schwelleneffekt. Unterhalb der Schwelle bringt menschliche Freigabe weiterhin Qualität.

Verwandt. Bullshit Factory, Self-Healing Production Line.

Narrator

Pattern.

Kontext. Ein Multi-Agenten-System wird komplexer, als ein Mensch beim Lesen der Logs nachvollziehen kann.

Problem. Ohne Erklärung, was das System getan hat, kann der Mensch Fehler nicht so beurteilen, dass er danach handeln kann.

Deshalb. Lasst einen Agenten die Aktivität des Systems in Erklärungen übersetzen, die ein Mensch lesen kann. Der Narrator interpretiert, statt zu berichten. Er wählt, was er hervorhebt, was er weglässt und welche Kausalzusammenhänge er explizit macht.

Worauf achten. Der Narrator ist die Voraussetzung für den Codification Imperative. Seine Qualität muss mit der Komplexität des Systems wachsen.

Verwandt. Agent Observability.

Codification Imperative

Pattern. Die Quelle nennt seine Wirkung auch die Automatisierungsratsche.

Kontext. Ein Mensch findet einen Fehlerfall, den die Factory nicht abdeckt, meist über den Narrator.

Problem. Ein Fix allein am Code repariert einen einzelnen Output. Die Factory bleibt so blind wie vorher.

Deshalb. Wendet die Regel an: kein manueller Fix ohne dauerhafte Korrektur. Kodifiziert jede menschliche Korrektur sofort, als Fitness Function, Testszenario oder Agentenregel. So erweitert der Fix das Produkt und zugleich die Logik der Factory.

Worauf achten. Jeder Zyklus erhöht die Komplexität des Systems. Das verlangt bessere Observability, die feinere Fehler findet und den nächsten Zyklus startet. Die Ratsche dreht nur in eine Richtung, und die Quelle nennt keine Obergrenze.

Verwandt. Mechanic, Narrator, Self-Healing Production Line.

Self-Healing Production Line

Pattern.

Kontext. Eine Factory hat mehrere Zyklen des Codification Imperative durchlaufen.

Problem. Fitness Functions, die nur als finale Gates laufen, fangen Verstöße spät ab und warten darauf, dass ein Mensch sie bemerkt.

Deshalb. Lasst Fitness Functions als kontinuierliche Monitore laufen. Ein erkannter Verstoß startet einen Korrektur-Agenten, ohne auf einen Menschen zu warten. Rechenkapazität, Parallelität der Agenten und Infrastrukturkosten behandelt ihr als gesteuerte Parameter.

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

Verwandt. Quality Inversion, Living Portfolio.

Full-Cycle Deployment

Pattern.

Kontext. Code verlässt die Factory und muss noch in Produktion kommen.

Problem. Ist das Deployment ein eigener Schritt nach der Factory, fallen Security, Laufzeitkonfiguration und Berechtigungen zurück in Handarbeit.

Deshalb. Macht das Deployment zum letzten Schritt der Factory. Qualitätsprüfungen, Security-Analyse und Laufzeitkonfiguration laufen im Factory-Lauf mit. Die Berechtigungen zur Laufzeit ergeben sich aus dem Code. Die Runtime skaliert mit der Last und kostet im Leerlauf nichts. Laufzeitfehler, die das System nicht lösen kann, eskalieren an Wartungsagenten.

Worauf achten. Was die Factory verlässt, ist korrekt und darüber hinaus produktionsreif, abgesichert und wartbar.

Verwandt. Ambient Identity, Sicherheit und Runtime-Isolation.

Ambient Identity

Pattern.

Kontext. Die Factory produziert viele Anwendungen für eine Organisation.

Problem. Wer Identität pro Anwendung löst, wiederholt dieselbe Arbeit und hinterlässt Lücken.

Deshalb. Macht Identität zu einer Infrastrukturschicht, die die Plattform vorschreibt. Jede Anwendung aus der Factory hängt automatisch am Identitätsmanagement der Organisation. Zur Laufzeit handelt sie im Namen der angemeldeten Person, mit deren Berechtigungen.

Worauf achten. Eine neue Lösung erreicht ab dem ersten Tag jeden Service und jeden Datenbestand, für den die nutzende Person berechtigt ist.

Verwandt. Full-Cycle Deployment, Citizen Development as a Platform.

Living Portfolio

Pattern.

Kontext. Die Zahl der Lösungen aus der Factory wächst ständig.

Problem. Braucht jeder Eintrag im Portfolio menschliche Wartung, steigen die Wartungskosten mit jeder Lösung.

Deshalb. Katalogisiert und dokumentiert jede neue Lösung, während sie entsteht. Lasst Wartungsagenten dauerhaft gegen jeden Eintrag laufen. Sie schließen Sicherheitslücken und erzeugen Dokumentation und Changelogs aus dem Code und seiner Änderungshistorie.

Worauf achten. Das Portfolio hält sich selbst gesund, auch bei Lösungen, die seit Monaten eigenständig laufen.

Verwandt. Self-Healing Production Line.

Citizen Development as a Platform

Pattern.

Kontext. Eine Organisation betreibt eine Dark Factory.

Problem. Fachexpert:innen, die eigene Software brauchen, warten auf ein Engineering-Team oder begnügen sich mit generischen Tools.

Deshalb. Lasst alle Fachexpert:innen eine Lösung direkt beauftragen, indem sie im Chat beschreiben, was sie brauchen. Die Factory übernimmt Anforderungen, Implementierung, Deployment, Identitätsintegration und die Aufnahme ins Portfolio.

Worauf achten. Für eine ganze Klasse von Lösungen verschwindet die Grenze zwischen “machbar” und “zu teuer”. Laut Quelle erhalten Abteilungen maßgeschneiderte Lösungen innerhalb von Tagen.

Verwandt. Ambient Identity, Living Portfolio.

Welche Tools nennt der Bericht?

• Obot, eine Plattform zur Verwaltung von MCP: Server, Registries, Audit-Logs, Nutzung, Filter, Scheduling, Agentenverwaltung, Token-Verbrauch, Modellanbieter und Zugriffsrichtlinien für Modelle.
• Backstage, das Entwicklerportal, mit Hintergrund-Agenten: Changelog-Generator, Code-Vereinfacher, Dependency-Upgrader, Dokumentation, Security-Review und SonarQube-Issue-Fixer.
• Amicable, das eigene Produkt von Mayflower. Damit bauen Menschen ohne Engineering-Hintergrund Apps auf freigegebenen Stacks, mit QA, Security und Observability der Organisation. Es bringt Templates für SPA, Full-Stack, API, Mobile und Desktop mit, über React, Vue, Svelte, Laravel, Phoenix, .NET und Quarkus.

Wie solltet ihr die Aussagen lesen?

Nehmt den Multiplikator als Rhetorik und testet die Patterns einzeln. Jedes davon lässt sich ohne die anderen testen: die Anti-Patterns, der Codification Imperative, Quality Inversion, Tests und Fitness Functions statt Spezifikationen und der Narrator. Messt jede Einführung an Durchsatz, Qualität und Change-Failure-Metriken, nicht an einem Multiplikator für die Schlagzeile.

Verwandte Seiten

• Software Factories und Harness Engineering: der Harness aus Gates und Regeln, in dem eine Dark Factory läuft.
• Creator- und Verifier-Rollen: wie ihr Verifikation mit einem Verifier aufbaut, der unabhängig vom Agenten ist, der den Code geschrieben hat.
• Software Factories in Produktion: Belege: was laufende Factories berichten und wo die Autonomie bei ausgeschaltetem Licht zusammenbrach.
• Agent Observability: die Aufzeichnung, auf die der Narrator und der Kodifizierungszyklus angewiesen sind.
• Sicherheit und Runtime-Isolation: die Laufzeitgrenzen, die eine Factory braucht, wenn sie ihren eigenen Code deployt.
• Federated Factory im Enterprise-Maßstab: wie sich Dark-Factory-Blueprints und interaktive Blueprints eine Plattform teilen.

Quellen

Artikel

• AI Dark Factory Patterns (öffnet in einem neuen Tab) - Der deutschsprachige Blogpost von Mayflower beschreibt vier Anti-Patterns und neun Patterns aus dem Bau einer Software Factory, die ohne Freigabe für jeden Schritt läuft.