Sechzehn Claude-Agenten, jeder in einem eigenen Docker-Container, haben in zwei Wochen einen C-Compiler mit 100.000 Zeilen Code gebaut. Der Compiler besteht 99 % der GCC Torture Test Suite. Er kompiliert den Linux-6.9-Kernel für x86, ARM und RISC-V. Gesamtkosten: 20.000 Dollar an API-Tokens. Kein Mensch hat den Code gelesen.
Dieses Projekt, veröffentlicht von Anthropics Nicholas Carlini im Februar 2026, ist das prominenteste Beispiel für das, was StrongDM eine “Software-Fabrik” nennt: ein System, in dem KI-Agenten Code durch strukturierte Schleifen schreiben, testen und iterieren, bis das Ergebnis definierte Konvergenzkriterien erfüllt. Menschen definieren das Ziel und den Test-Rahmen. Agenten erledigen den Rest.
Das ist kein Coding-Assistent, der die nächste Zeile vorschlägt. Das ist eine Produktionspipeline, in der Code von der Spezifikation zur funktionierenden Software fließt, ohne dass ein Mensch den Quellcode je liest.
So funktioniert eine Software-Fabrik
Die Grundidee kommt aus der Theorie dynamischer Systeme. Eine Trommelmaschine poliert Rohsteine durch wiederholte chaotische Bewegung. Einzelne Durchgänge sind zufällig, aber der Gesamtprozess konvergiert: raue Steine werden glatt. Software-Fabriken wenden dasselbe Prinzip auf Code an.
StrongDMs KI-Team (Justin McCarthy, Jay Taylor, Navan Chauhan) hat das in ihrem Software-Fabrik-Konzept formalisiert und Agate als Open-Source-Orchestrator veröffentlicht. Der Prozess läuft in fünf Phasen:
1. Interview. Das System liest ein Ziel (eine Markdown-Datei, die beschreibt, was gebaut werden soll) und generiert Rückfragen. Ein Mensch beantwortet sie. Das ist der letzte Punkt direkter menschlicher Eingabe.
2. Design. Agenten erstellen Architektur-Dokumente und technische Entscheidungen. Diese liegen als einfache Markdown-Dateien vor, nicht in einer Datenbank, sodass Menschen das Design bei Bedarf inspizieren und bearbeiten können.
3. Sprint-Planung. Das System zerlegt die Arbeit in Aufgaben und weist sie spezialisierten Agenten-Rollen zu: Planer, Codierer, Reviewer und Recovery-Agenten. Jede Rolle hat ihre eigene Skill-Definition.
4. Implementierungsschleife. Codierer schreiben Code. Reviewer prüfen jede Aufgabe. Lehnt ein Reviewer das Ergebnis ab, geht die Aufgabe zurück in die Schleife. Scheitert ein Codierer wiederholt, diagnostiziert ein Recovery-Agent den Fehler und ein Replanner formuliert die Aufgabe neu. Diese innere Schleife läuft ohne menschliche Aufsicht.
5. Bewertung. Nach jedem Sprint prüft das System, ob das ursprüngliche Ziel erreicht ist. Falls nicht, plant es automatisch einen weiteren Sprint.
Zwei Prinzipien definieren den StrongDM-Ansatz. Erstens: “Code darf nicht von Menschen geschrieben werden.” Zweitens: “Code darf nicht von Menschen reviewed werden.” Die Fabrik behandelt menschliches Code Review als Engpass, nicht als Sicherheitsmechanismus.
Das Konvergenzproblem
Der schwierige Teil ist nicht, Agenten zum Code-Schreiben zu bringen. Der schwierige Teil ist Konvergenz.
Anthropics Compiler-Projekt traf genau auf dieses Problem. Als alle 16 Agenten versuchten, den Linux-Kernel zu kompilieren, stießen sie auf dieselben Bugs, produzierten dieselben Fixes und überschrieben sich gegenseitig über Git. Sechzehn parallele Agenten waren effektiv ein einziger Agent, der sechzehnmal lief.
Die Lösung war ein Orakel: GCC als bekannt funktionierenden Compiler nutzen, um zufällige Teilmengen der Kernel-Dateien zu kompilieren, und Claudes Compiler nur am Rest testen. So konnte jeder Agent ein anderes Subsystem parallel debuggen. Die Agenten kollidierten nicht mehr und begannen zu konvergieren.
Agate löst das anders. Sein Sprint-Planer zerlegt Arbeit in unabhängige Aufgaben, und sein Reviewer verhindert, dass Agenten weiterarbeiten, bevor eine Aufgabe tatsächlich das Review besteht. Das Exit-Code-System (0 für fertig, 1 für mehr Arbeit, 2 für Fehler, 255 für menschliche Eingabe nötig) schafft klare Konvergenzkriterien auf Orchestrierungsebene.
Beide Ansätze teilen eine zentrale Erkenntnis: Konvergenz braucht Struktur. Autonome Agenten ohne Orchestrierung produzieren nur Chaos.
Agate und Factory.ai in der Praxis
StrongDM und Factory.ai repräsentieren zwei Pole des Software-Fabrik-Spektrums.
Agate: Open-Source-Orchestrierung
Agate ist ein Go-basiertes CLI-Tool, das lokal läuft. Man erstellt eine GOAL.md-Datei mit dem Bauziel, führt agate auto aus, und das System übernimmt. Der gesamte Zustand liegt in Markdown-Dateien unter einem .ai/-Verzeichnis: Interview-Protokolle, Architektur-Dokumente, Sprint-Pläne mit Checkbox-Tracking, Skill-Definitionen und vollständige Aufruf-Logs.
Das System unterstützt Claude Opus 4.5 (Standard), Claude 3.5 Haiku für schnelle Iteration und GPT-5.2 über das Codex-CLI. Eingebaute Rollen umfassen _planner, _reviewer, _recover, _replanner, _interviewer und _retro (für Sprint-Retrospektiven). Sprachspezifische Skills werden automatisch generiert: go-coder, python-reviewer und so weiter.
Was Agate auszeichnet, ist die Transparenz. Weil alles Markdown ist, kann man einen Fabrik-Lauf pausieren, genau lesen, was passiert ist, einen Sprint-Plan von Hand bearbeiten und fortsetzen. Der Systemzustand ist vollständig menschenlesbar, obwohl Menschen den produzierten Code nicht lesen sollen.
Factory.ai: Enterprise-Droids
Factory.ai geht den entgegengesetzten Weg: eine verwaltete Plattform mit spezialisierten Agenten namens “Droids”, die sich in bestehende CI/CD-Pipelines einklinken. Entwickler delegieren Aufgaben über ihre IDE (VS Code, JetBrains, Vim) oder das Terminal, und Droids übernehmen Implementierung, Review und Pull-Request-Erstellung.
Factory hat eine Series-B-Runde über 50 Millionen Dollar von NEA, Sequoia, J.P. Morgan und Nvidia eingeworben. Kunden sind unter anderem MongoDB, Ernst & Young, Zapier, Bayer und Clari, mit 200 % Quartals-Wachstum im Jahr 2025.
Das Unternehmen betont “Harness-Engineering” über rohe Modell-Fähigkeiten. Laut Factorys Eno Reyes in einem Stack-Overflow-Interview steckt die eigentliche Arbeit in “der Summe hunderter kleiner Optimierungen”: Kontext-Management, Umgebungsinjektion, Tool-Integration und Validierung von Qualitätssignalen.
Eine Stanford-Studie, die Factory zitiert, zeigt: Code-Qualität ist der einzige Prädiktor dafür, ob KI eine Organisation beschleunigt oder bremst. Nicht das Adoptionsvolumen. Nicht die Durchdringungsrate. Nur wie sauber die Codebasis ist, bevor Agenten sie anfassen.
Die 1.000-Dollar-pro-Entwickler-pro-Tag-Frage
StrongDMs Empfehlung für ihren Fabrik-Ansatz: 1.000 Dollar pro Tag an API-Tokens pro menschlichem Entwickler ausgeben. Das ergibt rund 20.000 Dollar pro Entwickler pro Monat, mehr als die meisten Junior-Entwicklergehälter im DACH-Raum und auf Augenhöhe mit Senior-Vergütung in vielen Regionen.
Anthropics Compiler-Projekt bestätigt diese Größenordnung. Sechzehn Agenten über zwei Wochen verbrauchten 2 Milliarden Input-Tokens und 140 Millionen Output-Tokens für insgesamt 20.000 Dollar. Das ergab 100.000 Zeilen funktionierenden Rust-Code für ein anspruchsvolles Systemprojekt.
Aber “funktionierend” braucht Einschränkungen. Der Compiler besteht 99 % der GCC Torture Suite, aber er kann keinen 16-Bit-x86-Code erzeugen, der für Linux-Boot-Sequenzen nötig ist. Sein Output ist weniger optimiert als GCC ohne jegliche Optimierungen. Für eine Forschungsdemonstration sind diese Lücken akzeptabel. Für Produktionsinfrastruktur nicht.
Die Ökonomie wird interessanter im Vergleich mit menschlichen Zeitlinien. GCC brauchte Tausende Ingenieure über 37 Jahre. Claudes Compiler brauchte einen Forscher (der die Orchestrierung aufsetzte und “hauptsächlich wegging”) und 16 Agenten für zwei Wochen. Selbst unter Berücksichtigung der Einschränkungen ist das Produktivitätsverhältnis enorm.
Digital-Twin-Universen
StrongDM hat ein weiteres Konzept eingeführt, das die Ökonomie verändert: Digital-Twin-Universen (DTUs). Das sind Verhaltensklone von Drittanbieter-Diensten wie Okta, Jira, Slack, Google Docs und Google Sheets. DTUs replizieren APIs, Grenzfälle und Verhalten, während sie Rate Limits und Kosten eliminieren.
Mit DTUs können Agenten “tausende Szenarien pro Stunde” gegen simulierte Umgebungen ausführen, statt reale APIs zu treffen. Das verschiebt die Erfolgsmetrik von binär (Tests bestehen oder nicht) zu probabilistisch: “Von allen beobachteten Trajektorien durch alle Szenarien, welcher Anteil erfüllt wahrscheinlich den Nutzer?”
Hier trennen sich Software-Fabriken von normalem Agent-Coding. Ein Coding-Assistent hilft beim Schreiben einer Funktion. Eine Software-Fabrik lässt die gesamte Anwendung gegen ein simuliertes Universum laufen, um herauszufinden, ob sie funktioniert.
Wo Software-Fabriken scheitern
Drei Probleme verhindern, dass Software-Fabriken heute konventionelle Entwicklung ersetzen.
Qualitätsobergrenzen. Agent-generierter Code funktioniert, aber er optimiert nicht. Anthropics Compiler erzeugt deutlich weniger effizienten Code als GCC ohne Optimierungen. Factorys Stanford-Studie bestätigt: Agenten beschleunigen gute Codebasen und bremsen schlechte. Wenn die Fabrik auf chaotischen Fundamenten startet, baut sie chaotische Gebäude.
Koordinationsaufwand. Anthropics Team stellte fest, dass 16 Agenten, die dasselbe Problem lösen, schlechter sind als ein Agent, es sei denn, man partitioniert die Arbeit bewusst. Agates Sprint-Planer und Factorys Droids adressieren das, aber keiner hat Benchmarks veröffentlicht, die lineare Skalierung mit der Agentenzahl zeigen. Die Koordinationssteuer ist real und schlecht verstanden.
Verantwortungslücken. Wenn kein Mensch den Code liest, wer verantwort sich, wenn er in Produktion versagt? Der EU AI Act klassifiziert KI-Systeme nach Risikoniveau, und autonome Code-Generierung für sicherheitskritische Anwendungen löst mit hoher Wahrscheinlichkeit Hochrisiko-Pflichten aus. StrongDMs Prinzip “kein menschliches Review” kollidiert direkt mit den Anforderungen an menschliche Aufsicht in Artikel 14 für Hochrisikosysteme. Für DACH-Unternehmen kommt die DSGVO hinzu: Wenn ein KI-Agent personenbezogene Daten verarbeitet, gelten die üblichen Dokumentations- und Rechenschaftspflichten, auch wenn kein Mensch den Verarbeitungscode geschrieben hat.
Was das für Entwicklungsteams bedeutet
Software-Fabriken ersetzen keine Entwickler. Sie ersetzen einen bestimmten Workflow: die Pipeline von der Spezifikation zum Pull Request, in der ein Entwickler ein klar definiertes Ticket erhält, es implementiert, selbst reviewt und einen PR öffnet.
Für diesen Workflow funktioniert das Fabrikmodell heute. Spezifikation definieren. Akzeptanzkriterien definieren. Agenten iterieren lassen, bis Konvergenz erreicht ist. Das Ergebnis auf Integrationsebene prüfen (tut es, was wir wollten?) statt auf Code-Ebene (ist diese Funktion gut geschrieben?).
Anthropics acht Trends für 2026 betonen genau diesen Wandel: Ingenieure wechseln vom Code-Schreiben zur Agenten-Koordination und konzentrieren ihre Expertise auf Architektur, Systemdesign und strategische Entscheidungen. Rakuten-Ingenieure nutzten Claude Code für eine Aufgabe in einer Codebasis mit 12,5 Millionen Zeilen und erledigten sie in sieben Stunden mit 99,9 % numerischer Genauigkeit.
Praktische Empfehlungen für Teams, die Software-Fabriken evaluieren:
Mit internen Tools beginnen. Anwendungen mit niedrigem Risiko und klarer Spezifikation, bei denen Liefergeschwindigkeit wichtiger ist als Code-Qualität. Agate ist kostenlos und Open Source. Testen Sie es an einem Wochenendprojekt, bevor Sie Produktions-Workloads darauf setzen.
In Test-Harness investieren, nicht in Code Review. Das Fabrikmodell steht und fällt mit der Qualität seiner Konvergenzkriterien. Carlinis wichtigste Lektion aus dem Compiler-Projekt: den Test-Rahmen für den Agenten designen, nicht für sich selbst. Explizites Fortschritts-Tracking, saubere Output-Formate und extrem hochwertige Tests zählen mehr als das Lesen von Agent-Code.
Die Kostenkurve beobachten. 20.000 Dollar pro Monat pro Entwickler ist für die meisten Teams heute unerschwinglich. Aber API-Token-Kosten sind seit 2023 um den Faktor 10 pro Jahr gesunken. Das StrongDM-Modell, das im Februar 2026 20.000 Dollar pro Monat kostet, könnte im Februar 2027 bei 2.000 Dollar pro Monat liegen.
Häufig gestellte Fragen
Was ist eine KI-Software-Fabrik?
Eine KI-Software-Fabrik ist ein System, in dem KI-Agenten Code durch strukturierte Plan-Implement-Review-Schleifen schreiben, testen und iterieren, bis das Ergebnis definierte Konvergenzkriterien erfüllt. Anders als Coding-Assistenten arbeiten Software-Fabriken ohne menschliches Code Review. Beispiele sind StrongDMs Agate-Orchestrator und Factory.ais Droids-Plattform.
Was kostet der Betrieb von KI-Agenten als Software-Fabrik?
StrongDM empfiehlt rund 1.000 Dollar pro Tag an API-Tokens pro menschlichem Entwickler, also etwa 20.000 Dollar pro Monat pro Entwickler. Anthropics C-Compiler-Projekt nutzte 16 parallele Agenten über zwei Wochen für insgesamt 20.000 Dollar und verbrauchte 2 Milliarden Input-Tokens und 140 Millionen Output-Tokens.
Was ist Agate von StrongDM?
Agate ist ein Open-Source-KI-Orchestrierungstool, das Softwareentwicklung automatisiert. Nutzer definieren ein Projektziel in einer Markdown-Datei, und Agate führt mehrere KI-Agenten durch iterative Plan-Implement-Review-Zyklen, bis das Ziel erreicht ist. Es unterstützt Claude Opus, Claude Haiku und GPT-5.2, wobei der gesamte Zustand als menschenlesbare Markdown-Dateien gespeichert wird.
Ist autonome Code-Generierung mit dem EU AI Act vereinbar?
Das hängt vom Einsatzbereich ab. Der EU AI Act klassifiziert KI-Systeme nach Risikoniveau. Autonome Code-Generierung für sicherheitskritische Anwendungen löst wahrscheinlich Hochrisiko-Pflichten aus, insbesondere die Anforderungen an menschliche Aufsicht in Artikel 14. Für interne Tools mit niedrigem Risiko sind die Anforderungen geringer. DACH-Unternehmen müssen zusätzlich DSGVO-Pflichten beachten, wenn KI-Agenten personenbezogene Daten verarbeiten.
Können KI-Agenten wirklich einen funktionierenden Compiler ohne menschliche Aufsicht bauen?
Ja. Anthropic hat das im Februar 2026 demonstriert, als 16 parallele Claude-Agenten einen 100.000-Zeilen-C-Compiler in Rust bauten, der 99 % der GCC Torture Test Suite besteht und den Linux-6.9-Kernel kompilieren kann. Der Compiler hat allerdings Einschränkungen: Er kann keinen 16-Bit-x86-Code generieren und erzeugt weniger optimierten Output als GCC ohne Optimierungen.