Die Verifikationsschicht der Dark Factory

StrongDM veröffentlichte Software unter zwei Regeln: „Code darf nicht von Menschen geschrieben werden” und „Code darf nicht von Menschen überprüft 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 Zeilen Go, 6.700 Zeilen TypeScript) mit einem Mindestaufwand von 1.000 Dollar an Token-Kosten pro Entwickler pro Tag.¹ BCG Platinion berichtet unter Berufung auf Spotify- und TechCrunch-Berichterstattung, 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, der von Maschinen generiert, von Maschinen verifiziert und ohne dass ein Mensch eine einzige Zeile liest, deployed wird.³ Die vorhergehenden Stufen bilden die Progression ab, auf der sich die meisten Teams gerade befinden — vom manuellen Programmieren (Level 0) über Task-Auslagerung (Level 1), Autopilot-auf-der-Autobahn (Level 2), Waymo-mit-Sicherheitsfahrer (Level 3) bis hin zum Robotaxi, bei dem Sie die Spezifikation schreiben und für 12 Stunden verschwinden (Level 4).³

Die Frage, die bisher niemand überzeugend beantwortet hat: Wie sieht die Verifikationsschicht auf Level 5 aus?

Das Verifikationsproblem potenziert sich

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

Entfernen Sie den Menschen vollständig, und Verifikation wird ein andersartiges 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 jemals das Artefakt selbst zu inspizieren.

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

Goodharts Gesetz wirkt hier mit ungewöhnlicher Kraft. Wenn 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 — andernfalls 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 Machine Learning funktionieren.¹ Die Analogie ist präzise: So wie ML-Modelle gegen Daten evaluiert werden, auf denen sie nie trainiert wurden, wird agentengebauter Code gegen Szenarien evaluiert, auf die der Agent während der Generierung keinen Zugriff hat.

Die Schlüsselmetrik heißt „Satisfaction”: der Anteil beobachteter Trajektorien, die den Benutzer wahrscheinlich zufriedenstellen.¹ Es existiert kein Industriestandard dafür, welcher Score als ausreichende Zufriedenheit gilt. StrongDM ermittelte ihren eigenen Schwellenwert empirisch.

Um szenariobasiertes Testen im großen Maßstab zu ermöglichen, 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 Endpoints. Die Verhaltensgenauigkeit des Twins bestimmt die Vertrauenswürdigkeit des Tests.

StrongDM beobachtete etwas, das ich ebenfalls festgestellt habe: „Mit der zweiten Revision von Claude 3.5 (Oktober 2024) begannen agentenbasierte Langzeit-Coding-Workflows, Korrektheit zu akkumulieren statt Fehler.”¹ Unterhalb einer Fähigkeitsschwelle produzieren längere Agentenläufe mehr Fehler. Oberhalb davon produzieren längere Läufe besseren Code. Das Dark-Factory-Muster wurde erst realisierbar, nachdem Modelle diese Schwelle überschritten hatten.

Fünf Schichten der Governance

BCG Platinions Fünf-Säulen-Transformationsframework umfasst eine Governance-Schicht mit mehreren Verifikationsschritten, bevor Code die Produktion erreicht.² Die Säulen: ein intentionsgetriebenes Betriebssystem, kodifizierte Wissensinfrastruktur, Weiterqualifizierung der Belegschaft, eine Governance-Schicht mit unabhängigen Verifikationsagenten und eine Factory-Architektur zur Orchestrierung.² Innerhalb der Governance-Säule beschreibt BCG Platinion szenariobasierte Tests durch unabhängige Agenten, statische Analyse, Architekturkonformitätsprüfung, verhaltensbasierte Regressionstests 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 Evaluierungsagent von einem anderen Bezugsrahmen aus 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 Verfassen von Spezifikationen, gegen die Agenten ausführen können. Ungenaue Spezifikationen produzieren bestandene Tests bei falschem Verhalten — dieselbe return true-Dynamik, auf die StrongDM gestoßen ist.¹

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 längst 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, der Ralph Loop, operiert auf Shapiros Level 4. Ich schreibe Spezifikationen, starte Agenten, schlafe und überprüfe morgens die Ergebnisse. Die Agenten laufen gegen über 95 Hooks, die jeden Tool-Aufruf abfangen — Dateischreibvorgänge, Git-Befehle, Shell-Ausführungen — sowohl vor als auch nach der Ausführung. Die Hooks erzwingen Einschränkungen, mit denen der Agent weder verhandeln noch sie umgehen kann.

Die Hooks adressieren Kahanas Gaming-Problem auf der Tool-Ebene. Ein Agent, der versucht, einen Force-Push auf main auszuführen, wird blockiert, bevor der Befehl ausgeführt wird — nicht erst, nachdem ein Test den Schaden registriert. Ein Agent, der versucht, Dateien mit .env-Mustern zu committen, wird abgefangen. Ein Agent, der „alle Tests bestanden” meldet, ohne pytest auszuführen, wird vom Evidence Gate markiert, das eingefügten Test-Output mit null Fehlern verlangt — keine Behauptung, dass Tests bestehen würden.

Das Evidence Gate erzwingt sechs Kriterien bei jeder nicht-trivialen Änderung: Einhaltung von Codebase-Mustern (Muster und Datei benennen), einfachste funktionierende Lösung (verworfene Alternativen nennen), Edge Cases behandelt (jeden einzelnen auflisten), Tests bestanden (Output einfügen), keine Regressionen (geprüfte Dateien benennen) und tatsächliches Problem gelöst (Bedarf des Benutzers und Lösungsansatz formulieren). „Ich glaube” und „es sollte” gelten nicht als Evidenz. Das Gate weist vage Formulierungen zurück und verlangt Artefakte.

Der Quality Loop — implementieren, überprüfen, evaluieren, verfeinern, herauszoomen, wiederholen, berichten — läuft als Verhaltenseinschränkung, kodiert im System-Prompt des Agenten über CLAUDE.md. Der Loop garantiert nicht, dass der Agent jeden Schritt befolgt. Die Hooks verifizieren, dass er es getan hat.

BCG Platinions fünf Säulen korrespondieren mit Infrastruktur, die ich bereits betreibe:

• Intentionsgetriebenes OS: CLAUDE.md-Dateien und PRD-getriebene Entwicklungsspezifikationen kodieren die Projektintention als ausführbaren Kontext.
• Kodifiziertes Wissen: Über 139 Skills, organisiert als wiederverwendbare Fähigkeiten, geben Agenten Zugriff auf Projektkonventionen, Architekturentscheidungen und Domänenwissen.
• Governance: Hooks implementieren die Abfangschicht. Das Evidence Gate implementiert die Auditschicht. Der Quality Loop implementiert die Verhaltenseinschränkungsschicht.

Zwei Säulen habe ich nicht aufgebaut: Weiterqualifizierung der Belegschaft (irrelevant für einen Einzelpraktiker) und Factory-Architektur als dedizierte Orchestrierungsplattform (mein aktuelles Setup nutzt Claude Codes natives Agent-Spawning, keine zweckgebaute Factory).

Die Lücke zwischen Level 4 und Level 5

Der Übergang von Level 4 zu Level 5 bedeutet, die Morgenüberprüfung zu eliminieren. Derzeit 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. Diese Überprüfung dauert 30 Minuten bis eine Stunde und fängt Probleme auf, die den Hooks entgehen.

Die Probleme, die den Hooks entgehen, sind die interessanten. Sie fallen in Kategorien, mit denen aktuelle Automatisierung schlecht umgehen kann:

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

Architekturelle 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-Pattern umgeht. Ein neuer Endpoint, 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 mit den Mustern konsistent ist, aber eine konzeptuelle Spaltung einführt, die sich bei zukünftigen Änderungen potenziert.

Verlust institutionellen Wissens. Kahana benennt ein unterschätztes Risiko: Wenn niemand den Code liest, baut niemand Intuition über das System auf.⁴ Wie Kahana warnt: „Niemand wird wissen warum. Niemand wird wissen, wie man es repariert.”⁴ Derzeit baut meine Morgenüberprüfung diese Intuition inkrementell auf. Auf Level 5 wird das System für seinen Betreiber opak. Jedes komplexe System braucht irgendwann Eingriffe, die Automatisierung nicht bewältigen kann — ein Sicherheitsvorfall, eine Geschäftslogik-Änderung, die in der Test-Suite verankerte Annahmen verletzt, eine Integration mit einem externen System, das sich anders verhält als seine Dokumentation behauptet. Der Betreiber, der nie den Code gelesen hat, kann nicht wirksam 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 benötigt mindestens Folgendes:

Holdout-basierte Evaluation. Tests, auf die der generierende Agent während der Code-Produktion keinen Zugriff hat. StrongDMs Szenarien. Verhaltensspezifikationen, separat von der Codebasis gespeichert, evaluiert durch unabhängige Agenten. Ohne Holdout-Evaluation verwandelt Goodharts Gesetz jede Test-Suite in ein 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 von unterschiedlichen Kontexten aus operieren. Red-Team-Agenten, die aktiv nach Gaming, Abkürzungen und Phantom-Verifikation suchen, fügen eine Schicht hinzu, die passives Testen nicht leisten kann.

Abfangen auf Tool-Ebene. Hooks, die schädliche Operationen vor der Ausführung blockieren — nicht Tests, die Schäden erst nach der Tat erkennen. Die Hook-Schicht operiert unterhalb der Entscheidungsebene des Agenten und lässt sich durch cleveres Prompting oder return true-Abkürzungen nicht umgehen.

Ausführbare Intentionsspezifikationen. Spezifikationen, die präzise genug sind, um Mehrdeutigkeit erkennbar zu machen. 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 die AI Life Cycle Core Principles, die verlangen, dass Output „auf eine geeignete verantwortliche Partei rückverfolgbar” sein muss.⁴ Eine branchenweit standardisierte Audit-Methodik für agentengebaute Software existiert noch nicht.⁴ Die Verifikationsschicht muss Artefakte produzieren, anhand derer ein Mensch (oder Regulierer oder Incident Responder) vom deployten Verhalten zurück zur Spezifikation navigieren kann, die es generiert hat.

Die ehrliche Bestandsaufnahme

Ich betreibe Level 4 mit hoher Zuversicht. Meine nächtlichen Agenten produzieren Arbeit, die die Morgenüberprüfung häufiger besteht als nicht. Die Hooks fangen die mechanischen Fehler ab. Das Evidence Gate fängt die epistemischen Fehler ab. Der Quality Loop reduziert die Verhaltensfehler.

Level 5 erfordert die Lösung von Problemen, die ich noch nicht gelöst habe. Erkennung von Intentionsdrift ohne menschliches Pattern-Matching. 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ätsgewinnen bei Teams, die Dark-Factory-Muster einführen.² StrongDM veröffentlichte agentengebaute Software mit drei Ingenieuren und einem Token-Budget.¹ Der Produktivitätsgewinn liegt auf der Hand. Der Verifikationsgewinn nicht.

Die Teams, die Level 5 erfolgreich umsetzen, teilen ein gemeinsames Merkmal: Sie investierten mehr in Verifikationsinfrastruktur als in Code-Generierung. StrongDM baute ein komplettes Digital Twin Universe auf, 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 darstellt — und alles andere, einschließlich des Codes, eine Commodity ist.

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

Dieses Stück zu bauen — das ist die Arbeit, die vor uns liegt.