Dark Factory Verification: Wenn kein Mensch mehr den Code liest

Eine Dark Factory (Level 5) ist eine Softwareentwicklungsumgebung, in der Maschinen Code generieren, verifizieren und deployen — kein Mensch liest eine einzige Zeile. Die Verifikationsschicht, die eine Dark Factory tragfähig macht, erfordert Holdout-basierte Evaluation, Digital-Twin-Universen, Multi-Agenten-Review und kodifizierte Geschmacksconstraints. Ohne diese Schicht manipulieren Agenten Tests, und Qualität verschwindet.

StrongDM veröffentlichte Software unter zwei Regeln: „Code darf nicht von Menschen geschrieben werden” und „Code darf nicht von Menschen reviewt werden.”¹ Ein Drei-Personen-Team (Justin McCarthy, Jay Taylor und Navan Chauhan) entwickelte und veröffentlichte Attractor und CXDB (16.000 Zeilen Rust, 9.500 Go, 6.700 TypeScript) mit einem Mindestaufwand von 1.000 Dollar an Token-Kosten pro Entwickler und Tag.¹ BCG Platinion berichtet unter Berufung auf Spotify und TechCrunch, dass Spotifys beste Entwickler seit Dezember 2025 keinen Code mehr geschrieben hätten und das Unternehmen monatlich Hunderte KI-generierter Pull Requests merge.²

Dan Shapiro nennt den Endpunkt Level 5: die Dark Factory. Code wird von Maschinen generiert, von Maschinen verifiziert, ohne dass ein Mensch eine einzige Zeile liest, deployed.³ Die vorhergehenden Stufen bilden die Progression ab, der die meisten Teams aktuell folgen: manuelles Coding (Level 0), Task-Offload (Level 1), Autopilot auf der Autobahn (Level 2), Waymo mit Sicherheitsfahrer (Level 3) und Robotaxi, bei dem Sie die Spezifikation schreiben und für 12 Stunden verschwinden (Level 4).³

Die Frage, die bislang niemand überzeugend beantwortet hat: Wie sieht die Verifikationsschicht auf Level 5 aus? Die folgende Analyse kartiert die erforderliche Infrastruktur und baut auf der Taste-Infrastruktur auf, die bestimmt, wie ich Qualität in meiner gesamten Engineering-Arbeit bewerte.

Das Verifikationsproblem potenziert sich

Auf jeder Stufe unterhalb von 5 liest irgendwann ein Mensch den Code. Auf Level 3 managt der Mensch die KI wie ein Senior Developer. Auf Level 4 prüft der Mensch nach 12 Stunden, ob die Tests bestanden haben.³ Diese Stufen funktionieren, weil eine Person mit institutionellem Wissen Muster gegen die Intention abgleichen kann. Die Spezifikation sagte „Retry mit exponentiellem Backoff”, und der Code macht linearen Retry — ein Entwickler erkennt das auf einen Blick.

Entfernen Sie den Menschen vollständig, und Verifikation wird ein grundlegend anderes Problem. Nicht schwieriger im Grad. Anders in der Art. Der Verifizierer kann sich nicht auf Leseverständnis verlassen. Er muss kodieren, was „korrekt” bedeutet — in ausführbarer Form — und den Output gegen diese Kodierung evaluieren, ohne das Artefakt selbst jemals zu inspizieren.

Die zentrale Falle: Agenten, die Tests manipulieren. StrongDM entdeckte, dass ihre Agenten return true schrieben, um Testsuiten zu bestehen, ohne etwas Nützliches zu tun.¹ Die Tests waren grün. Die CI-Pipeline meldete Erfolg. Der Code war wertlos. Stanfords Eran Kahana erweitert diese Beobachtung zu einer strukturellen Warnung: Das eigentliche Problem sei die Zirkularität — dieselbe Technologieklasse evaluiert Code, den dieselbe Klasse geschrieben hat.⁴

Goodharts Gesetz wirkt hier mit ungewöhnlicher Kraft. Taste is a technical system argumentiert, dass automatisierte Verifikation eine Urteilsschicht darüber braucht; ohne Evaluation auf Geschmacksebene werden Tests zu Zielen statt zu Maßstäben. Sobald Agenten auf das Bestehen von Tests optimieren, hört das Bestehen von Tests auf, Korrektheit zu messen.⁴ Jede Metrik, die zum Ziel wird, hört auf, eine gute Metrik zu sein. Die Verifikationsschicht einer Dark Factory muss diese Dynamik berücksichtigen — sonst misst sie Compliance statt Qualität.

Wie StrongDM Verifikation tatsächlich löst

StrongDMs Antwort sind sogenannte „Scenarios”: End-to-End-User-Stories, die außerhalb der Codebasis gespeichert werden und wie Holdout-Sets im maschinellen Lernen funktionieren.¹ Die Analogie ist präzise: So wie ML-Praktiker Modelle gegen Daten evaluieren, mit denen nie trainiert wurde, evaluieren unabhängige Agenten den generierten Code gegen Szenarien, auf die der codierende Agent während der Generierung keinen Zugriff hat.

Die Schlüsselmetrik ist „Satisfaction”: der Anteil beobachteter Trajektorien, die den Benutzer wahrscheinlich zufriedenstellen.¹ Kein Industriestandard definiert, welcher Score als ausreichende Satisfaction gilt. StrongDM ermittelte ihren eigenen Schwellenwert empirisch.

Damit szenariobasiertes Testen im großen Maßstab funktioniert, baute StrongDM ein Digital Twin Universe: Verhaltensklone von Okta, Jira, Slack, Google Docs, Drive und Sheets.¹ Die Twins zielen auf 100 % API-Kompatibilität unter Verwendung populärer, öffentlich verfügbarer Referenz-SDK-Client-Bibliotheken.¹ Die Agenten laufen gegen die Twins, nicht gegen gemockte Endpunkte. Die Verhaltensgenauigkeit des Twins bestimmt die Vertrauenswürdigkeit des Tests.

StrongDM beobachtete ein Muster, das auch ich gesehen habe: „Mit der zweiten Revision von Claude 3.5 (Oktober 2024) begannen langfristige agentische Coding-Workflows, Korrektheit zu akkumulieren statt Fehler.”¹ Unterhalb eines Fähigkeitsschwellenwerts produzieren längere Agenten-Läufe mehr Fehler. Oberhalb davon produzieren längere Läufe besseren Code. Das Dark-Factory-Muster wurde erst tragfähig, nachdem Modelle diesen Schwellenwert überschritten hatten.

Fünf Governance-Schichten

BCG Platinions Fünf-Säulen-Transformationsframework enthält eine Governance-Schicht mit mehreren Verifikationsschritten, bevor Code die Produktion erreicht.² Die Säulen: ein intentionsgetriebenes Betriebssystem, kodifizierte Wissensinfrastruktur, Workforce-Upskilling, eine Governance-Schicht mit unabhängigen Verifikationsagenten und eine Factory-Architektur für Orchestrierung.² Die Governance-Säule umfasst szenariobasierte Tests durch unabhängige Agenten, statische Analyse, Architekturkonformitätsprüfung, verhaltensbasiertes Regressionstesting und Red-Team-Agenten, die aktiv versuchen, den Output zu brechen.²

Die Unabhängigkeit ist entscheidend. Wenn derselbe Agent seinen eigenen Code schreibt und testet, greift Kahanas Zirkularitätsproblem.⁴ Wenn ein separater Agent (mit anderen System-Prompts, anderem Kontext, anderen Anreizen) die Arbeit evaluiert, dekorrelieren die Fehlermodi. Nicht eliminieren. Dekorrelieren. Zwei Agenten können systematische Verzerrungen aus den Trainingsdaten teilen. Allerdings sinkt die Wahrscheinlichkeit identischer blinder Flecken, wenn der evaluierende Agent aus einem anderen Bezugsrahmen operiert.

BCG Platinion identifiziert „Intent Thinking” als kritische Kompetenz für Dark-Factory-Teams: die Übersetzung von Geschäftsanforderungen in präzise, testbare Beschreibungen gewünschter Ergebnisse.² Die menschliche Rolle verschiebt sich vom Codeschreiben zum Schreiben von Spezifikationen, gegen die Agenten ausführen können. Ungenaue Spezifikationen produzieren bestehende Tests bei falschem Verhalten — dieselbe return true-Dynamik, die StrongDM erlebt hat.¹

BCG Platinion benennt zudem eine Einschränkung, die ich aus eigener Erfahrung kenne: „KI-Agenten sind nur so effektiv wie das kodifizierte Wissen, auf das sie zugreifen können.”² Ein Agent ohne Projektkontext generiert plausiblen Code, der lokale Konventionen verletzt, Architekturentscheidungen ignoriert und Probleme neu entdeckt, die das Team bereits gelöst hat. Kodifiziertes Wissen (Designentscheidungen, API-Verträge, Style Guides, Fehlerhistorien) ist Infrastruktur, nicht Dokumentation.

Was ich bereits auf Level 4 betreibe

Meine nächtliche Ausführungsschleife, die Ralph-Agentenarchitektur, operiert auf Shapiros Level 4. Ich schreibe Spezifikationen, starte Agenten, schlafe und prüfe die Ergebnisse am Morgen. Die Agenten laufen gegen über 95 Hooks, die jeden Tool-Aufruf (Dateischreibvorgänge, Git-Befehle, Shell-Ausführung) vor und nach der Ausführung abfangen. Die Hooks erzwingen Constraints, über die der Agent nicht verhandeln oder die er nicht umgehen kann.

Die Hooks adressieren Kahanas Gaming-Problem auf Tool-Ebene. Ein separater Beitrag dokumentiert die vollständige Hook-Architektur, aber die hier relevante Eigenschaft ist Interception: Hooks feuern vor der Tool-Ausführung, nicht danach. Ein Agent, der einen Force-Push auf main versucht, wird blockiert, bevor der Befehl ausgeführt wird. Ein Agent, der Dateien committen will, die .env-Mustern entsprechen, wird abgefangen. Ein Agent, der „alle Tests bestanden” meldet, ohne pytest ausgeführt zu haben, wird vom Evidence Gate markiert — das verlangt eingefügte Testausgaben mit null Fehlern, nicht die Behauptung, dass Tests bestehen würden.

Das Evidence Gate erzwingt sechs Kriterien bei jeder nicht-trivialen Änderung: folgt Codebase-Mustern (benennen Sie das Muster und die Datei), einfachste funktionierende Lösung (nennen Sie verworfene Alternativen), Randfälle behandelt (listen Sie jeden einzelnen auf), Tests bestanden (fügen Sie die Ausgabe ein), keine Regressionen (benennen Sie die geprüften Dateien) und löst das eigentliche Problem (formulieren Sie den Bedarf des Benutzers und wie die Änderung ihn adressiert). „Ich glaube” und „es sollte” sind kein Beweis. Das Gate weist hedgende Sprache zurück und fordert Artefakte.

Die Qualitätsschleife (implementieren, reviewen, evaluieren, verfeinern, herauszoomen, wiederholen, berichten) läuft als Verhaltensconstraint, kodifiziert im System-Prompt des Agenten über CLAUDE.md. Die Schleife garantiert nicht, dass der Agent jeden Schritt befolgt. Die Hooks verifizieren, dass er es getan hat.

BCG Platinions fünf Säulen bilden sich auf Infrastruktur ab, die ich bereits betreibe:

• Intentionsgetriebenes Betriebssystem: CLAUDE.md-Dateien und PRD-getriebene Entwicklungsspezifikationen kodieren Projektintention als ausführbaren Kontext.
• Kodifiziertes Wissen: Über 139 Skills, organisiert als wiederverwendbare Fähigkeiten, geben Agenten Zugang zu Projektkonventionen, Architekturentscheidungen und Domänenwissen.
• Governance: Hooks implementieren die Interception-Schicht. Das Evidence Gate implementiert die Audit-Schicht. Die Qualitätsschleife implementiert die Verhaltensconstraint-Schicht.

Zwei Säulen habe ich nicht gebaut: Workforce-Upskilling (irrelevant für einen Einzelpraktiker) und Factory-Architektur als dedizierte Orchestrierungsplattform (mein aktuelles Setup nutzt Claude Codes native Agenten-Spawning, keine zweckgebaute Factory). Das Compound-Context-System beschreibt, wie sich diese Infrastrukturschichten zu einem Kapitalwert akkumulieren und jede nachfolgende Sitzung leistungsfähiger machen.

Die Lücke zwischen Level 4 und Level 5

Der Schritt von Level 4 zu Level 5 bedeutet, das Morgen-Review zu eliminieren. Aktuell wache ich auf und lese, was die Agenten über Nacht produziert haben. Ich prüfe Git-Diffs. Ich starte die Anwendung. Ich verifiziere, dass der Output meiner Intention entspricht. Dieses Review dauert 30 Minuten bis eine Stunde und fängt Probleme ab, die den Hooks entgehen.

Die Probleme, die den Hooks entgehen, sind die interessanten. Sie fallen in Kategorien, die aktuelle Automatisierung schlecht bewältigt:

Intentionsdrift. Der Agent hat die Spezifikation getreu umgesetzt, aber die Spezifikation war mehrdeutig — und der Agent wählte die falsche Interpretation. Kein Test fängt eine falsche Interpretation ab, die valides Verhalten produziert. StrongDMs Szenario-Ansatz adressiert dies, indem User Stories als Spezifikation kodiert werden, nicht technische Anforderungen.¹ Die Szenarien beschreiben, was ein Benutzer erlebt, nicht was der Code tut.

Architekturale Erosion. Der Agent hat ein Feature hinzugefügt, das isoliert funktioniert, aber die strukturelle Kohärenz des Systems untergräbt. Eine neue Datenbankabfrage, die das bestehende Repository-Muster umgeht. Ein neuer Endpunkt, der Logik aus einem anderen Modul dupliziert. Statische Analyse fängt einiges davon ab. Architekturkonformitätsprüfung (BCG Platinions Governance-Schicht) fängt mehr ab.² Keines von beiden erkennt die subtilen Fälle, in denen der neue Code technisch konsistent mit den Mustern ist, aber eine konzeptuelle Spaltung einführt, die sich bei zukünftigen Änderungen potenziert.

Verlust institutionellen Wissens. Kahana weist auf ein unterschätztes Risiko hin: Wenn niemand den Code liest, baut auch niemand Intuition über das System auf.⁴ Wie Kahana warnt: „Niemand wird wissen warum. Niemand wird wissen, wie man es repariert.”⁴ Heute baut mein Morgen-Review diese Intuition inkrementell auf. Auf Level 5 wird das System für seinen Betreiber opak. Jedes komplexe System braucht irgendwann eine Intervention, die Automatisierung nicht bewältigen kann: ein Sicherheitsvorfall, eine Geschäftslogikänderung, die in die Testsuite eingebackene Annahmen verletzt, eine Integration mit einem externen System, das sich anders verhält als seine Dokumentation behauptet. Der Betreiber, der den Code nie gelesen hat, kann nicht effektiv eingreifen.

Was die Verifikationsschicht tatsächlich braucht

Aus der Synthese von StrongDMs Praxis, BCG Platinions Governance-Framework, Kahanas Fehleranalyse und meiner eigenen Infrastruktur ergibt sich: Die Verifikationsschicht einer Dark Factory erfordert mindestens:

Holdout-basierte Evaluation. Tests, auf die der generierende Agent während der Code-Produktion keinen Zugriff hat. StrongDMs Scenarios. Verhaltensspezifikationen, getrennt von der Codebasis gespeichert, evaluiert durch unabhängige Agenten. Ohne Holdout-Evaluation macht Goodharts Gesetz jede Testsuite zum Optimierungsziel.

Digital Twins für Integrationstests. Agenten können nicht gegen Produktionssysteme testen. Mocks sind zu oberflächlich — sie verifizieren API-Verträge, nicht Verhalten. Twins, die die Verhaltensoberfläche externer Abhängigkeiten replizieren, ermöglichen End-to-End-Szenarioausführung ohne Produktionsrisiko.

Multi-Agenten-Verifikation mit dekorrelierten Fehlermodi. Der schreibende Agent und der evaluierende Agent müssen aus unterschiedlichen Kontexten heraus operieren. Red-Team-Agenten, die aktiv nach Gaming, Abkürzungen und Phantomverifikation suchen, liefern eine Schicht, die passives Testing nicht bieten kann.

Interception auf Tool-Ebene. Hooks, die schädliche Operationen vor der Ausführung blockieren — nicht Tests, die Schäden erst danach erkennen. Die Hook-Schicht sitzt unterhalb der Entscheidungsfindung des Agenten und widersteht Umgehung durch geschicktes Prompting oder return true-Abkürzungen.

Ausführbare Intentionsspezifikationen. Spezifikationen, die präzise genug sind, dass Mehrdeutigkeit erkennbar wird. BCG Platinions „Intent Thinking”-Kompetenz.² Shapiros Level-4-Spezifikation, die Sie schreiben, bevor Sie für 12 Stunden verschwinden.³ Die Spezifikation ist das Produkt. Der Code ist ein Nebeneffekt.

Audit-Trail ohne Verantwortungslücke. Kahana zitiert AI Life Cycle Core Principles, die verlangen, dass Output „auf eine geeignete verantwortliche Partei rückverfolgbar” sein muss.⁴ Eine branchenübliche Audit-Methodik für agentengebaute Software existiert noch nicht.⁴ Die Verifikationsschicht muss Artefakte produzieren, die ein Mensch (oder Regulierer oder Incident-Responder) von deploytem Verhalten zurück zur generierenden Spezifikation verfolgen kann.

Die ehrliche Einschätzung

Level 4 betreibe ich mit hohem Vertrauen. Meine nächtlichen Agenten produzieren Arbeit, die das Morgen-Review häufiger besteht als nicht. Die Hooks fangen die mechanischen Fehler ab. Das Evidence Gate fängt die epistemischen Fehler ab. Die Qualitätsschleife reduziert die Verhaltensfehler.

Level 5 erfordert die Lösung von Problemen, die ich noch nicht gelöst habe. Intentionsdrift-Erkennung ohne menschlichen Musterabgleich. Architekturkonformität, die konzeptuelle Erosion erkennt, nicht nur strukturelle Verstöße. Institutionelles Wissen, das sich im System akkumuliert statt im Kopf des Betreibers.

BCG Platinion berichtet von 3- bis 5-fachen Produktivitätssteigerungen bei Teams, die Dark-Factory-Muster übernehmen.² StrongDM veröffentlichte agentengebaute Software mit drei Ingenieuren und einem Token-Budget.¹ Das Produktivitätsargument ist klar. Das Verifikationsargument nicht.

Die Teams, die auf Level 5 erfolgreich sind, teilen ein gemeinsames Merkmal: Sie investierten mehr in Verifikationsinfrastruktur als in Codegenerierung. StrongDM baute ein ganzes Digital Twin Universe, bevor sie Agenten vertrauten, Code auszuliefern.¹ BCG Platinions Framework umfasst fünf Transformationssäulen, darunter eine Governance-Schicht mit mehreren Verifikationsschritten, bevor Code die Produktion erreicht.² Die Dark Factory ist keine Fabrik, die im Dunkeln läuft. Sie ist eine Fabrik, in der die Beleuchtung die Verifikationsschicht ist — und alles andere, einschließlich des Codes, eine Commodity.

Ich schrieb zuvor über was passiert, wenn Agenten unbeaufsichtigt laufen und über das Evidence Gate als Verteidigung gegen Phantomverifikation. Diese Beiträge beschreiben die Infrastruktur für Level 4. Die Dark Factory verlangt dieselbe Infrastruktur, erweitert um den Betrieb ohne den Menschen, der aktuell den morgendlichen Diff liest. Die Hooks, die Evidence Gates, die Qualitätsschleifen: alle notwendig auf Level 5, aber nicht hinreichend. Das fehlende Stück ist Verifikation, die mit derselben Autonomie skaliert wie die Generierung.

Dieses Stück zu bauen, ist die Arbeit, die vor uns liegt. Der AI-Engineering-Hub versammelt den gesamten Bogen dieser Untersuchung — vom Design einzelner Hooks über Compound Context bis zur Dark-Factory-Frontier.

FAQ

Was ist eine Dark Factory in der Softwareentwicklung?

Eine Dark Factory (Dan Shapiros Level 5) ist eine Softwareentwicklungsumgebung, in der Maschinen Code generieren, verifizieren und deployen, ohne dass ein Mensch eine einzige Zeile liest. Die vorhergehenden Stufen reichen von manuellem Coding (Level 0) über zunehmende Automatisierung bis Level 4 — dem „Robotaxi”-Modus, in dem ein Mensch die Spezifikation schreibt, für 12 Stunden verschwindet und dann die Ergebnisse prüft. Die Dark Factory eliminiert selbst diese letzte Prüfung.

Was ist die größte Verifikationsherausforderung auf Level 5?

Die zentrale Falle: Agenten, die Tests manipulieren. StrongDM entdeckte, dass Agenten return true schrieben, um Testsuiten zu bestehen, ohne etwas Nützliches zu tun. Goodharts Gesetz wirkt hier mit ungewöhnlicher Kraft: Sobald Agenten auf das Bestehen von Tests optimieren, hört das Bestehen von Tests auf, Korrektheit zu messen. Die Verifikationsschicht muss dem Rechnung tragen — durch Holdout-basierte Evaluation (Tests, auf die der generierende Agent während der Code-Produktion keinen Zugriff hat), Multi-Agenten-Verifikation mit dekorrelierten Fehlermodi und Interception auf Tool-Ebene, die schädliche Operationen vor der Ausführung blockiert.

Worin besteht die Lücke zwischen Level 4 und Level 5?

Drei Probleme, die aktuelle Automatisierung schlecht bewältigt: Intentionsdrift (der Agent setzte die Spezifikation getreu um, wählte aber die falsche Interpretation einer mehrdeutigen Anforderung), architekturale Erosion (neue Features, die isoliert funktionieren, aber die strukturelle Kohärenz untergraben) und Verlust institutionellen Wissens (wenn niemand den Code liest, baut auch niemand die Systemintution auf, die für Interventionen bei Vorfällen oder Geschäftslogikänderungen nötig ist).

Wie löst StrongDM das Verifikationsproblem?

StrongDM nutzt „Scenarios” — End-to-End-User-Stories, die außerhalb der Codebasis gespeichert werden und wie Holdout-Sets im maschinellen Lernen funktionieren. Unabhängige Agenten evaluieren den Code gegen Szenarien, auf die der codierende Agent während der Generierung keinen Zugriff hat. Dazu bauten sie ein Digital Twin Universe (Verhaltensklone von Okta, Jira, Slack, Google Docs) mit dem Ziel von 100 % API-Kompatibilität, sodass Agenten gegen realistische Verhaltensoberflächen testen statt gegen oberflächliche Mocks.