- 16 Claude-Agenten arbeiteten parallel zusammen und stellten einen Rust-basierten C-Compiler fertig, der ein Niveau erreichte, auf dem sich der Linux-6.9-Kernel bauen lässt
- Mit rund 2.000 Sitzungen und Kosten von 20.000 US-Dollar wurden etwa 100.000 Zeilen Code erzeugt; unterstützt werden die Architekturen x86, ARM und RISC-V
- Die Agenten arbeiteten über ein automatisches Loop-Harness kontinuierlich ohne menschliche Eingriffe weiter und steigerten die Effizienz durch Tests, Parallelisierung und Rollenverteilung
- Das Ergebnis zeigte GCC-Kompatibilität und hohe Erfolgsquoten in Tests, doch 16-Bit-x86-Codegenerierung, Linker und Optimierungsqualität sind noch unvollständig
- Das Experiment gilt als Beispiel zur Überprüfung von Grenzen und Möglichkeiten autonomer LLM-Teams; künftig rücken Sicherheit und Qualitätskontrolle vollständig autonomer Entwicklungsumgebungen als zentrale Aufgaben in den Vordergrund
Überblick über das C-Compiler-Projekt auf Basis eines Agenten-Teams
- Ein Experiment, bei dem mehrere Claude-Instanzen parallel zusammenarbeiten, um eine gemeinsame Codebasis zu entwickeln
- Ohne menschliche Eingriffe in Echtzeit wiederholen sie eigenständig das Schreiben, Testen und Korrigieren von Code
- Ziel war es, einen in Rust geschriebenen C-Compiler fertigzustellen und damit den Linux-Kernel direkt zu bauen
- Insgesamt wurden 16 Agenten, rund 2.000 Sitzungen sowie 200 Millionen Input-Token und 140 Millionen Output-Token eingesetzt
- Das Ergebnis ist ein Compiler mit 100.000 Zeilen Code, mit dem sich der Linux-6.9-Kernel und wichtige Open-Source-Projekte (QEMU, FFmpeg, SQLite, Redis usw.) bauen lassen
Entwurf des Claude-Harness für lange Laufzeiten
- Bisher benötigte Claude Code menschliche Eingaben, doch mit einem automatischen Ausführungs-Harness in einer Endlosschleifen-Struktur wurde autonomer Betrieb möglich
- Nach Abschluss jeder Aufgabe folgt sofort die nächste in einer automatischen Wiederholungsstruktur
- Während der Arbeit kam es auch vor, dass Claude versehentlich
pkill -9 bash ausführte und sich damit selbst beendete
- Die parallele Ausführungsstruktur nutzt Docker-Container und Git-Synchronisierung
- Jeder Agent arbeitet in
/workspace und pusht danach nach /upstream
- Locks auf Basis von Textdateien verhindern Arbeitskonflikte
- Merge-Konflikte löst Claude selbst
Betriebsweise des parallelen Claude-Setups
- Der Vorteil der Parallelausführung liegt in gleichzeitigem Debugging und differenzierten Rollen
- Einige Agenten schreiben Code, andere übernehmen Dokumentation, Qualitätskontrolle und Performance-Optimierung
- Es gibt weder Kommunikation noch einen zentralen Koordinator; jeder Agent wählt die nächste Aufgabe eigenständig aus
- In der Git-Historie bleiben Arbeits-Locks und Fortschrittsdokumente der einzelnen Agenten erhalten
Erkenntnisse aus dem Team-Programming mit Claude
Bedeutung hochwertiger Tests
- Claude arbeitet autonom anhand der vorgegebenen Tests, daher ist die Genauigkeit des Verifikators entscheidend
- Bei False Positives entwickelt sich die Arbeit in die falsche Richtung weiter
- Es wurde eine Continuous-Integration-(CI)-Pipeline aufgebaut, um verbindlich zu prüfen, dass bestehende Funktionen nicht kaputtgehen
- Zur Qualitätssicherung wurden Open-Source-Build-Skripte und Compiler-Test-Suites eingesetzt
Umgebungsdesign aus Claudes Perspektive
- Jeder Agent startet in einem neuen Container ohne Kontext, daher ist die Dokumentation des Fortschritts unverzichtbar
- Es wurde angewiesen, README und Fortschrittsdateien fortlaufend zu aktualisieren
- Zur Vermeidung von Kontextverschmutzung werden Logs minimiert, und Fehler werden so protokolliert, dass sie über das Schlüsselwort
ERROR erkennbar sind
- Um das fehlende Zeitbewusstsein auszugleichen, wurden mit der Option
--fast 1–10-%-Stichprobentests durchgeführt
Grenzen der Parallelisierung und Lösungen
- Wenn viele unabhängige Tests vorhanden sind, ist Parallelisierung einfach; der Build des Linux-Kernels ist jedoch eine einzelne große Aufgabe, bei der Konflikte auftreten
- Als Lösung wurde GCC als Referenz-Compiler-Orakel verwendet
- Einige Dateien wurden mit GCC, die übrigen mit dem Claude-Compiler gebaut
- Bei Fehlschlägen ließ sich die problematische Datei eingrenzen und parallel debuggen
- Anschließend wurden mit Delta-Debugging wechselseitige Abhängigkeitsfehler erkannt
Differenzierte Rollen der Agenten
- Spezialisierte Aufgabenverteilung für Entfernung von Duplikat-Code, Performance-Verbesserungen, effiziente Codegenerierung, Verbesserung der Rust-Struktur und Dokumentation
- Die Kombination aus Parallelität und Spezialisierung steigerte die Effizienz bei der Verwaltung großer Codebasen
Leistungsbewertung des Modells Opus 4.6
- Bis Opus 4.5 war der Build großer Projekte nicht möglich; erst mit Opus 4.6 wurde erstmals ein praktisch nutzbares Niveau erreicht
- Als Cleanroom-Implementierung wurde ohne Internetzugang ausschließlich die Rust-Standardbibliothek verwendet
- 99 % der GCC torture test suite bestanden, Doom ist lauffähig
- Einschränkungen:
- Keine 16-Bit-x86-Codegenerierung, daher ist in der Boot-Phase ein GCC-Aufruf erforderlich
- Assembler und Linker sind unvollständig, einige Bugs bestehen noch
- Die Effizienz des erzeugten Codes ist niedrig und schlechter als bei deaktivierten GCC-Optimierungen
- Die Qualität des Rust-Codes ist ordentlich, erreicht aber kein Expertenniveau
Grenzen und Potenzial autonomer Agenten-Teams
- Das Projekt dient als Benchmark zur Messung der Grenzen autonomer Zusammenarbeit von LLMs
- Vollständig autonome Entwicklung bringt Qualitätssicherung und Sicherheitsrisiken mit sich
- Es besteht das Risiko, das Bestehen von Tests fälschlich mit Fertigstellung gleichzusetzen
- Es werden Bedenken gegenüber der Bereitstellung von Code ohne menschliche Verifikation geäußert
- Zugleich wird gezeigt, dass autonome Agenten-Teams komplexe Projekte abschließen können
- Mit der Weiterentwicklung der Modelle werden Strategien für sichere autonome Entwicklung zu einer zentralen Aufgabe
Ausblick
- Die Entwicklung von Sprachmodellen verläuft von IDE-Autovervollständigung → Funktionsvervollständigung → Pair Programming → autonomer Projektausführung
- Agent teams zeigen die Möglichkeit vollständig autonomer Entwicklung
- Angesichts des schnellen technologischen Fortschritts werden Überraschung ebenso wie die Notwendigkeit neuer ethischer und sicherheitsbezogener Rahmenwerke betont
- Es wird erwartet, dass positive Einsatzmöglichkeiten negative Risiken überwiegen, zugleich ist jedoch Vorbereitung auf ein neues Entwicklungsparadigma notwendig
Noch keine Kommentare.