Das KI- und Infrastrukturteam von Google hat in einem Blogbeitrag, den die meisten in der Branche überflogen haben, etwas still und leise Bemerkenswertes veröffentlicht: eine sechsfache Beschleunigung bei der Migration von Produktions-Maschinenlernmodellen von TensorFlow zu JAX, und das in einem Umfang mit Tausenden von Codezeilen, Hunderten von Schichten und tiefgreifenden Abhängigkeiten über mehrere Dateien hinweg. Sundar Pichai erwähnte es auf der Bühne der Google Cloud Next. Die Zahl schaffte es in die Schlagzeilen. Die darunterliegende Architektur ist die eigentliche Geschichte, und es ist dieselbe Architektur, die hinter jeder glaubwürdigen groß angelegten Agentenmigration steckt, die gerade stattfindet, egal ob der Schwarm aus 8 oder 800 Agenten besteht.
Hier ist das entscheidende Detail: Sie versuchten zuerst, einen einzelnen KI-Agenten auf die Codebasis anzusetzen. Es scheiterte. Nicht nur teilweise. Er verlor den Kontext, halluzinierte APIs, die es nicht gab, und produzierte Code, der nicht kompilierte. Die Lösung war kein intelligenteres Modell. Es war eine völlig andere Architektur, eine mit einem Namen: das „Dark Factory“-Muster, eine Codebasis, in der Agenten planen, implementieren, testen und Code ausliefern, ohne dass ein Mensch im Kreislauf ist – so wie eine vollautomatisierte Fabrik im Dunkeln läuft, weil niemand mehr da ist, um das Licht anzumachen.
Dieser Artikel ist die vollständige Aufschlüsselung dieses Musters. Nicht die Marketing-Version. Die tatsächliche Mechanik, wie Hunderte von Agenten eine echte Codebasis migrieren, ohne dass ein Mensch jede einzelne Änderung überprüft, und warum das, was es sicher macht, nicht das Vertrauen in das Modell ist, sondern eine Architektur, die speziell dafür entwickelt wurde, dieses Vertrauen gar nicht erst zu benötigen.
Warum ein einzelner Agent im großen Maßstab scheitert
Bevor wir zur Architektur kommen, verstehen Sie genau, warum der naive Ansatz bricht, denn jede Designentscheidung im funktionierenden Muster existiert speziell, um einen dieser Fehler zu beheben.
Ein einzelner Agent, der auf eine große Codebasis angesetzt wird, stößt zuerst auf ein Kontextproblem. Selbst mit einem großzügigen Kontextfenster übersteigt eine Codebasis mit Hunderten von voneinander abhängigen Dateien, tiefen Aufrufketten und übernommenen Annahmen zwischen Modulen das, was eine einzelne Sitzung kohärent halten kann. Der Agent startet stark bei den ersten paar Dateien und lässt nach, wenn der Arbeitskontext mit angesammelter, halb relevanter Historie gefüllt wird.
Dann stößt er auf ein Sequenzierungsproblem. Codemigration ist standardmäßig keine parallele Aufgabe. Datei B hängt oft davon ab, dass Datei A bereits migriert wurde, weil sich die Funktionssignaturen geändert haben, die Importe verschoben wurden oder die Datenstrukturen ihre Form geändert haben. Ein Agent ohne eine explizite Abhängigkeitskarte rät entweder die Reihenfolge, was zu defekten Zwischenzuständen führt, oder verarbeitet Dateien in der Reihenfolge, in der sie zufällig aufgelistet wurden, was funktional dasselbe ist wie Raten.
Dann stößt er auf ein Verifikationsproblem, und das ist dasjenige, das tatsächlich am wichtigsten ist. Ein Agent, der Code migriert und dann seine eigene Migration bewertet, überprüft seine eigenen Hausaufgaben mit genau den blinden Flecken, die überhaupt zu Fehlern geführt haben. Wenn der Agent nicht versteht, dass sich eine bestimmte API unter einer neuen Version anders verhält, wird er dieses Missverständnis nicht bemerken, wenn er seine eigene Ausgabe überprüft, weil dieselbe Verständnislücke in beiden Durchgängen vorhanden ist.
Das Team von Google hat das direkt herausgefunden. Der Einzelagenten-Setup konnte die strukturellen Regeln der Migration nicht gleichzeitig mit den zeilenweisen Ausführungsdetails in Einklang bringen. Diese beiden Anliegen in separate Rollen aufzuteilen, ist die eigentliche Lösung, und es ist dieselbe Lösung, die unabhängig voneinander in OpenAIs veröffentlichtem Migrations-Kochbuch, in der akademischen Forschung zu Multi-Agenten-Migrationsschleifen und in jedem Produktionssystem, das dies tatsächlich im großen Maßstab betreibt, auftaucht.
Die Architektur: Drei Rollen, kein Generalist
Das funktionierende Muster teilt die Aufgabe in Rollen mit wirklich unterschiedlichen Aufgaben auf, nicht nur in verschiedene Eingabeaufforderungen, die auf denselben Generalisten-Agenten gerichtet sind.
Ein Planer, der deterministische Werkzeuge verwendet, keine LLM-Schätzung, um die Arbeit zu sequenzieren. Dies ist das Detail, das ein System, das tatsächlich skaliert, von einem trennt, das in einer Demo beeindruckend aussieht und in der Produktion auseinanderfällt. Der Planer von Google bittet kein LLM, die Migrationsreihenfolge durch logisches Denken herauszufinden. Er verwendet compilerbasierte statische Analyse, dieselbe Kategorie deterministischer Werkzeuge, die seit Jahrzehnten Unternehmenssoftware untermauert, um den tatsächlichen Abhängigkeitsbaum zu erstellen und einen Ausführungsplan zu definieren, der bei Blattknoten (Dateien, von denen nichts anderes abhängt) beginnt und sich zu Dateien hocharbeitet, von denen alles andere abhängt.
Dies ist wichtig, weil die Abhängigkeitsreihenfolge kein kreatives Problem ist. Es ist ein mechanisches mit einer richtigen Antwort, und die Verwendung eines LLM zur Lösung eines Problems, das bereits eine deterministische Lösung hat, führt nur eine neue Fehlerquelle ein, wo keine existieren muss. Die Regel dahinter: Überall dort, wo ein Problem eine algorithmische Antwort hat, verwenden Sie den Algorithmus. Reservieren Sie das Sprachmodell für den Teil der Aufgabe, der wirklich Urteilsvermögen erfordert, nämlich die eigentliche Codetransformation, nicht die Sequenzierung, welche Datei zuerst kommt.
Ein Migrationsagent (oder, in größeren Systemen, Hunderte von ihnen, die parallel laufen, isolierte, eng gefasste Instanzen derselben Rolle), der die eigentliche Codetransformation durchführt. Jede Instanz erhält eine abgegrenzte Aufgabe, idealerweise eine Datei oder ein eng begrenztes Modul, einen einzigen Checkout und eine explizite Migrationsanweisung, die genau beschreibt, was geändert werden muss und warum. Er inspiziert den relevanten Code, nimmt die Änderungen vor und erstellt einen Patch. Er entscheidet nicht, ob sein eigener Patch korrekt ist. Das ist nicht sein Job, und die Architektur ist speziell so ausgelegt, dass er diesen Job nicht versehentlich übernehmen kann.
Eine Umgebungs- und Verifikationsebene, die den migrierten Code in einer isolierten Umgebung erstellt, ausführt und testet, bevor etwas akzeptiert wird. Hier wird „erledigt ist erledigt“ zu einer mechanischen Tatsache statt einer Meinung. Die Formulierung von Google ist präzise: Die Branche hatte historisch zwei schlechte Optionen, um zu entscheiden, wann die Arbeit einer KI tatsächlich abgeschlossen ist: menschliche Überprüfung, die nicht auf Hunderte von Dateien skaliert, oder KI-Selbstevaluierung, die nicht geprüft werden kann, weil es keine Aufzeichnung darüber gibt, was tatsächlich überprüft wurde. Ihre Antwort ist mathematische Verifikation, deterministischer Code, der bestätigt, dass die Kompilierung erfolgreich ist, Tests bestanden werden und das Verhalten einer definierten Spezifikation entspricht, und ersetzt beide schlechten Optionen durch eine dritte, die tatsächlich überprüfbar ist.
Beachten Sie, was in dieser Liste fehlt: ein Mensch, der jedes einzelne Diff liest, bevor es zusammengeführt wird. Das ist der springende Punkt des Dark-Factory-Musters, und es ist auch genau der Punkt, an dem die Intuition der meisten Menschen in Bezug auf Sicherheit falsch liegt, weil es sich so anhört, als würde das System den Agenten einfach mehr vertrauen. Es ist das Gegenteil. Es vertraut den Agenten strukturell weniger, indem es den einzelnen Beurteilungspunkt – „Hat der Agent gesagt, dass das funktioniert hat?“ – durch eine Verifikationsebene ersetzt, die der Agent weder beeinflussen noch umgehen kann.
Die Isolationsebene: Warum jeder Agent seine eigene Sandbox bekommt
Hunderte von Agenten gleichzeitig gegen dieselbe Codebasis laufen zu lassen, birgt ein offensichtliches Risiko: Was passiert, wenn Agent 47 mitten in der Bearbeitung einer Datei ist, von der die Änderung von Agent 12 abhängt, und die Bearbeitung von Agent 12 gerade die Kompilierung zerstört hat.
Die Antwort, die sowohl in OpenAIs veröffentlichter Migrationsarchitektur als auch in Googles Produktionssystem konsistent ist, ist Isolation als Standard. Jede Migrationsaufgabe läuft in ihrer eigenen Sandbox-Umgebung, oft einem eigenen Git-Worktree, einem vollständigen, unabhängigen Checkout des relevanten Repositorys, das auf diese eine Aufgabe beschränkt ist. Wenn ein Agent in dieser Sandbox etwas kaputt macht, zerstört er eine isolierte Kopie, nicht die gemeinsame Codebasis und schon gar nicht die laufende Arbeit eines anderen Agenten.
Diese Isolation bewirkt mehr als nur die Verhinderung von Kollisionen. Sie macht das gesamte System trivial parallelisierbar, da es keinen gemeinsamen veränderlichen Zustand gibt, auf den Hunderte von gleichzeitigen Agenten treten könnten. Agent 1 bis Agent 800 können wirklich gleichzeitig laufen, jeder in einer sauberen Umgebung, die nur die für seine spezifische Aufgabe relevanten Dateien und den Kontext enthält, ohne dass das Risiko besteht, dass die Halluzination eines Agenten die korrekte Arbeit eines anderen kontaminiert.
Das Geschirr, die Orchestrierungsebene, die entscheidet, welche Aufgabe an welche Sandbox geht und was mit dem resultierenden Patch passiert, bleibt außerhalb jeder einzelnen Sandbox. Dies ist eine spezifische und wichtige architektonische Entscheidung: Der vertrauenswürdige Prozess mit Zugriff auf Geheimnisse, externe Tools und das eigentliche Repository lebt getrennt von der nicht vertrauenswürdigen Ausführungsumgebung, in der der KI-generierte Code tatsächlich läuft. Die Sandbox bekommt genau das, was sie für ihre eine Aufgabe braucht, nicht mehr. Der Host-Prozess führt niemals generierten Code direkt mit seinen eigenen erhöhten Berechtigungen aus. Diese Trennung macht es sicher, den Code eines Agenten überhaupt ausführen zu lassen, da ein Fehler oder sogar eine feindselige Eingabeaufforderungsinjektion innerhalb der Sandbox keinen Pfad zu etwas außerhalb hat.
Die Schleife selbst: Planen, Ausführen, Verifizieren, Verfeinern
Entfernt man den Maßstab und die spezifischen Werkzeuge, hat die eigentliche Schleife, die all dem zugrunde liegt, vier Phasen, die sich pro Aufgabe wiederholen, bis diese Aufgabe bestanden ist oder ihr Wiederholungsbudget erschöpft ist.
Phase eins: Migrationsplanung. Der Migrationsagent erhält seine abgegrenzte Aufgabe, eine Datei oder ein Modul, die spezifische Zielvorgabe (Sprachversion, Framework-Änderung, API-Kompatibilitätsanforderungen) und erstellt eine Kandidatentransformation. Dies ist die einzige Phase, in der kreatives, urteilsbasiertes Denken des Sprachmodells die primäre Arbeit leistet, da die Entscheidung, wie ein bestimmtes Muster korrekt in sein Äquivalent in einem neuen Framework übersetzt wird, wirklich Verständnis erfordert, nicht nur mechanisches Nachschlagen.
Phase zwei: Automatisierte Umgebungseinrichtung. Eine separate Komponente, in der akademischen Literatur zu diesem Muster manchmal als Umgebungsagent bezeichnet, konstruiert autonom eine Build- und Laufzeitumgebung für den migrierten Code, kümmert sich um die Abhängigkeitsauflösung und Konfiguration, sodass der Kandidatenpatch tatsächlich unter realistischen Bedingungen kompiliert und ausgeführt werden kann, anstatt abstrakt bewertet zu werden.
Phase drei: Testvalidierung. Der migrierte Code wird gegen die tatsächliche Testsuite ausgeführt oder gegen ein generiertes Äquivalent, falls für dieses spezifische Modul keine Testsuite existiert. Dies ist der mechanische Verifikationsschritt, der ein objektives Bestehen oder Nichtbestehen und nicht einen Eindruck liefert. Entweder die Tests bestehen oder nicht, und es gibt keine Mehrdeutigkeit, die ein Agent umgehen könnte.
Phase vier: Feedback-Verfeinerung. Bei einem Fehlschlag werden die spezifischen Testfehler und Diagnoseprotokolle als gezielte Korrektureingabe an den Migrationsagenten zurückgesendet, nicht als vages „Das hat nicht funktioniert, versuch es noch einmal.“ Der Agent, dem der Patch gehört, verfeinert seine spezifische Logik und Abhängigkeitszuordnung basierend auf konkreten Beweisen dafür, was kaputt gegangen ist, nicht auf einem generischen Neustart von Grund auf.
Dieser vierteilige Zyklus wiederholt sich pro Aufgabe, mit einer definierten Obergrenze. Eine dokumentierte, funktionierende Version dieses exakten Schleifenmusters gibt eine Stoppbedingung wie „Keine Dateien entsprechen mehr dem alten Muster“ zusammen mit einer harten maximalen Iterationsanzahl an, in einem veröffentlichten Beispiel 200 Iterationen, nach denen das System automatisch anhält, anstatt unbegrenzt bei einer Aufgabe zu laufen, die nicht konvergiert.
Diese Obergrenze ist im großen Maßstab enorm wichtig. Ohne sie würde eine Aufgabe, die strukturell unmöglich zu erledigen ist, weil die Spezifikation selbst mehrdeutig ist oder das Zielmuster wirklich kein sauberes Äquivalent hat, unbegrenzt Ressourcen verbrauchen, anstatt als spezifischer, begrenzter Fehler aufzutauchen, den ein Mensch tatsächlich ansehen und beheben kann.
Warum menschliche Überprüfung nicht skaliert und was sie ersetzt
Es ist wichtig, genau zu sein, warum „Kein Mensch überprüft jeden einzelnen“ hier tatsächlich das sicherere Design ist, keine Ecke, die abgeschnitten wird.
Die Forschung, die die Codeüberprüfung durch KI-Agenten mit der menschlichen Codeüberprüfung vergleicht, hat etwas Spezifisches und Nützliches ergeben: KI-generierte Überprüfungskommentare sind pro Codezeile fast siebenmal länger als menschliche Überprüfungen und konzentrieren sich fast ausschließlich auf Codeverbesserung und Fehlererkennung, während sich die menschliche Überprüfung auf ganz andere Dinge verteilt: Aufbau eines gemeinsamen Verständnisses, Wissensaustausch, soziale Kommunikation zwischen Teammitgliedern. Der Hin und Her bei der menschlichen Überprüfung variiert enorm je nach Art des Feedbacks. Die KI-zu-KI-Überprüfungsinteraktion ist weitaus einheitlicher und mechanischer, unabhängig davon, was beanstandet wird.
Wenn man das richtig liest, sagt es etwas Wichtiges aus: Menschliche Überprüfung und KI-Verifikation sind gut in strukturell unterschiedlichen Dingen. Einen Menschen zu bitten, 800 einzelne Diffs mit der Geschwindigkeit und dem Volumen zu überprüfen, mit dem ein Agentenschwarm sie produziert, ist kein Sicherheits-Upgrade, sondern ein Engpass, der zu einer Abnick-Genehmigung führt, weil kein Mensch eine echte Prüfung über dieses Volumen aufrechterhalten kann. Die tatsächliche Sicherheit im Dark-Factory-Muster kommt nicht von der Entfernung der Verifikation. Sie kommt vom Ersetzen einer Art von Verifikation – langsamer, ermüdender, inkonsistenter menschlicher Aufmerksamkeit, die über Hunderte von sich wiederholenden Diffs verteilt ist – durch eine andere Art, die skaliert: deterministische Build- und Testvalidierung, die bei Diff 1 und Diff 800 die gleiche Strenge liefert, ohne Ermüdungserscheinungen.
Dies ist auch genau der Grund, warum die Planungsphase compilerbasierte statische Analyse anstelle von LLM-Urteilsvermögen für die Sequenzierung verwendet. Überall dort im System, wo eine deterministische Prüfung eine Beurteilung ersetzen kann, sollte sie es, denn deterministische Prüfungen sind der einzige Teil dieser Architektur, der im Nachhinein wirklich überprüfbar ist. Sie können genau das wiederholen, was ein statischer Analysator gefunden hat. Sie können nicht vollständig wiederholen, warum ein Sprachmodell „das Gefühl“ hatte, dass eine bestimmte Migrationsreihenfolge richtig war.
Was noch einen Menschen braucht und wo die Grenze tatsächlich verläuft
Dieses Muster bedeutet nicht „Menschen vollständig entfernen und hoffen“. Jede glaubwürdige veröffentlichte Version davon – Googles Produktionssystem, die akademische Environment-in-the-Loop-Forschung, OpenAIs eigenes Kochbuch – zieht eine explizite Grenze dafür, wo menschliches Urteilsvermögen obligatorisch bleibt.
Der konsistente Befund aus einer quantitativen Studie zu agentengesteuerten Bibliotheksmigrationen: Agenten erreichen zuverlässig eine hohe Migrationsabdeckung, indem sie korrekt identifizieren, welche API-Änderungen erforderlich sind, haben aber speziell Schwierigkeiten, das Gesamtverhalten der Anwendung in den komplexeren Fällen zu bewahren, in denen eine erfolgreiche Migration das Verständnis der Absicht erfordert, nicht nur das Pattern-Matching der Syntax. Die Empfehlung, die direkt aus diesem Befund folgt, ist ein Human-in-the-Loop-Kontrollpunkt speziell für die Teilmenge von Dateien, die die deterministische Verifikation als risikoreich oder mit geringem Vertrauen kennzeichnet, nicht für die gesamte Charge.
In der Praxis führt dies zu einem abgestuften System. Dateien, die die statische Abhängigkeitsanalyse als klein, gut isoliert und strukturell einfach einstuft – der Großteil jeder echten Migration – durchlaufen die vollautomatisierte Schleife ohne menschlichen Eingriff, abgesehen vom deterministischen Build- und Test-Gate. Dateien, die als komplex, tief vernetzt oder die geschäftskritische Logik betreffend gekennzeichnet sind, werden vor dem Zusammenführen in eine Warteschlange für eine tatsächliche menschliche Überprüfung geleitet, selbst innerhalb eines ansonsten vollautomatisierten Systems.
Dieser abgestufte Ansatz ist die realistische Version von „800 Agenten, null Menschen überprüfen jeden einzelnen“. Es ist nicht so, dass nie ein Mensch etwas ansieht. Es ist so, dass das System speziell dafür ausgelegt ist, die 95 % der mechanischen, risikoarmen Arbeit durch vollständige Automatisierung zu leiten, während die knappe Ressource – echtes menschliches Urteilsvermögen – ausschließlich auf den kleinen Teil der Fälle konzentriert wird, in dem es tatsächlich einen Mehrwert bietet, den die deterministische Verifikation nicht replizieren kann.
Aufbau für Ihre eigene Codebasis
Das Muster skaliert nach unten genauso sauber wie nach oben. Dieselben vier Rollen gelten, egal ob Sie 800 parallele Agenten gegen eine riesige Produktionscodebasis oder eine Handvoll sequenzieller Migrationsaufgaben gegen ein einzelnes Repository ausführen.
Beginnen Sie mit dem Planer, und widerstehen Sie dem Drang, ihn zu einem LLM zu machen. Wenn Ihre Migration irgendeine Art von Abhängigkeitsstruktur hat – Dateiimporte, gemeinsame Schnittstellen, Build-Reihenfolge – verwenden Sie tatsächliche statische Analysetools, die für Ihre Sprache geeignet sind, um diesen Abhängigkeitsgraphen mechanisch zu erstellen. Diese einzelne Entscheidung ist die mit der höchsten Hebelwirkung im gesamten System, da jede nachgelagerte Phase alle Sequenzierungsfehler erbt, die der Planer macht.
Grenzen Sie jede einzelne Aufgabe so eng ein, wie es der Abhängigkeitsgraph zulässt. Eine Datei, ein Modul, eine klar abgegrenzte Änderungseinheit mit einer expliziten Anweisung, die genau beschreibt, was passieren muss und warum. Widerstehen Sie der Versuchung, mehrere nicht zusammenhängende Änderungen aus Gründen der Effizienz in einer Aufgabe zu kombinieren, denn ein enger Umfang macht die Bestehen/Nichtbestehen-Beurteilung der Verifikationsphase eindeutig.
Isolieren Sie die Ausführung jeder Aufgabe. Ein frischer Git-Worktree pro Aufgabe als Minimum, eine vollständige Sandbox-Umgebung, wenn Sie dies in einem nennenswerten Maßstab betreiben. Dies ist kein optionaler Infrastrukturaufwand. Es ist das, was die Parallelisierung sicher macht und den Fehler eines einzelnen Agenten eingedämmt und nicht ansteckend macht.
Bauen Sie die deterministische Verifikation, bevor Sie irgendetwas anderes bauen. Kompilierungserfolg, Bestehensrate der Testsuite, Verhaltensäquivalenzprüfungen, wo Sie sie konstruieren können. Dies ist die Komponente, die „Hat der Agent gesagt, dass es funktioniert hat“ durch „Hat es tatsächlich funktioniert“ ersetzt, und es ist die einzelne Komponente, die die meisten selbstgebauten Migrationsversuche vollständig überspringen, was genau der Grund ist, warum diese Versuche in jedem sinnvollen Maßstab scheitern.
Begrenzen Sie die Wiederholungsschleife explizit, mit einer Zahl, nicht mit einem Gefühl. Definieren Sie, wie „Diese Aufgabe steckt fest“ aussieht, bevor Sie etwas ausführen, und leiten Sie feststeckende Aufgaben automatisch in eine menschliche Warteschlange, anstatt sie unbegrenzt Ressourcen verbrauchen zu lassen oder, schlimmer noch, stillschweigend einen falschen Erfolg zu melden.
Die eigentliche Lektion unter der Schlagzeilenzahl
Was auch immer die tatsächliche Zahl ist, die in einer bestimmten groß angelegten Migration läuft – 800 Agenten oder 80 oder 8.000 – die Schlagzeilenzahl ist der am wenigsten interessante Teil der Geschichte. Der interessante Teil ist, dass keinem dieser Agenten individuell vertraut wird, zu entscheiden, ob ihre eigene Arbeit korrekt ist, und das gesamte System ist um dieses Misstrauen herum entworfen, nicht trotz ihm.
Eine Dark Factory läuft nicht im Dunkeln, weil niemand zusieht. Sie läuft im Dunkeln, weil das Zusehen vollständig in die Maschinerie selbst verlagert wurde, in Compiler-Checks und Test-Suites und Abhängigkeitsgraphen, die jedes einzelne Mal die gleiche rigorose Antwort liefern, bei Datei eins und Datei achthundert, ohne Ermüdung und ohne die Inkonsistenz, die entsteht, wenn man einen Menschen bittet, denselben sich wiederholenden Beurteilungsaufruf Tausende von Malen hintereinander durchzuführen.
Das ist das tatsächliche Muster hinter jeder Version davon, die gerade in der Produktion funktioniert. Nicht mutigeres Vertrauen in größere Modelle. Eine diszipliniertere Weigerung, irgendeiner einzelnen Komponente, ob Mensch oder KI, zu erlauben, der alleinige Richter ihrer eigenen Arbeit zu sein.
Folgen Sie @cyrilxbt für weitere KI-Inhalte
