Aufbau eines C-Compilers mit einem parallelen Claude-Team

• 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

[mammal]

Da es sich nicht um einen in C geschriebenen Compiler handelt, sondern um ein Projekt, das ausschließlich mit der Rust-Standardbibliothek erstellt wurde, wirkt die Kritik, dass gcc/clang-C-Code in den Trainingsdaten enthalten sei, auf mich eher wie ein Verschieben der Torpfosten. Wie dem auch sei, das ist beeindruckend.

[GN⁺]

Hacker-News-Kommentare

• Ich habe fast zehn Jahre lang bei Google daran gearbeitet, den Linux-Kernel mit Clang zu bauen. Dieses Projekt (clangbuiltlinux.github.io) soll dasselbe mit einem LLM, 2.000 Sitzungen und API-Kosten von 20.000 Dollar geschafft haben. Dass es tatsächlich bis zum Booten gekommen sein soll, ist erstaunlich. Allerdings ist die Effizienz des erzeugten Codes gering und sogar schlechter als eine nicht optimierte GCC-Version. Trotzdem ist es ein wirklich großartiges Projekt

  • Großartig ist es schon, aber vielleicht ist das Ergebnis am Ende nur von den Hausaufgaben anderer abgeschrieben
  • Es heißt, Opus habe keinen 16-Bit-x86-Codegenerator implementieren können und deshalb beim Boot-Schritt mit einem Workaround GCC aufgerufen. Da fragt man sich, ob es wirklich selbst gebootet hat
  • Das fühlt sich an, als käme die Zeit von Ken Thompsons „Trusting Trust“ zurück. Vielleicht pflanzt sich KI bald selbst ins Innere von Compilern ein
  • Wenn es 20.000 Dollar gekostet hat, hätte man für das Geld auch kurzzeitig acht Senior-Entwickler engagieren können. Es wirkt, als sei zu viel in Marketing geflossen, und das eigentliche Geschäftsmodell bleibt unklar

• Das ist viel realistischer als das Cursor-Browser-Projekt. Es heißt, es sei eine Cleanroom-Implementierung, nur mit der Rust-Standardbibliothek und ohne Internetzugang. Ein Compiler mit 100.000 Zeilen soll Linux 6.9, QEMU, FFmpeg, SQLite, Postgres und Redis bauen können.
  Opus 4.5 habe erstmals große Tests bestehen können, und dieses Ergebnis scheint diese Grenze nahezu vollständig auszureizen.
  Trotz vieler Einschränkungen halte ich das für ein beeindruckendes Experiment

  • Die Bezeichnung „Cleanroom-Implementierung“ wirkt übertrieben. Das Modell wurde bereits auf dem gesamten Internet und dessen C-Compilern trainiert, daher braucht man diesen Ausdruck eigentlich nicht
  • Es wäre schade, so ein Ergebnis nur anhand des heutigen Stands zu bewerten. Wenn man sich das Entwicklungstempo der letzten Monate ansieht, dürfte es in einem Jahr jede Vorstellung übertreffen
  • Eigentlich ist das weniger ein Cleanroom als vielmehr ein Fall, in dem ein LLM während des Trainings komprimiertes Wissen testbasiert wieder entfaltet hat
  • Es wurde vermutlich ohnehin mit GCC- oder Clang-Code trainiert; mich würde interessieren, wie ähnlich es dem echten Code tatsächlich ist
  • Ich persönlich finde es zwar beeindruckend, aber aus Sicht realer Nutzer weniger spannend. Sinnvoller wäre es vielleicht, eine neue ISA zu LLVM hinzuzufügen oder einen Compiler für eine neue Sprache zu bauen

• Zuerst dachte ich: „Wow, beeindruckend“, aber dann habe ich meine Meinung geändert. Ein C-Compiler ist Software mit sehr strenger Spezifikation, also vergleichsweise leicht für ein LLM zu handhaben.
  Die meisten Dinge, an denen wir arbeiten, haben aber unklare Anforderungen und Ziele, die sich ständig ändern. Ich frage mich, ob es auch in solchen Bereichen gut funktionieren würde

  • Über die Aussage „C-Compiler sind klar definiert“ muss ich lachen. Wie viel „unspecified behavior“ es da gibt
  • Dass die Codegenerierung auf Tests hin optimiert wird, ähnelt dem Fitten eines ML-Modells. Menschen müssen die Tests weiterhin entwerfen und validieren

• Die Erwartung, dass das Ergebnis perfekt sein müsse, fühlt sich seltsam an. Schon dass es überhaupt möglich ist, ist erstaunlich. Solche Versuche könnten in das Training des nächsten Opus oder Sonnet einfließen, und irgendwann erscheint vielleicht ein Modell, das selbst effiziente Compiler baut

  • Ich sehe das genauso. Es geht nicht darum, wie gut der Hund tanzt, sondern dass er überhaupt tanzt
  • Zurzeit ist die Abneigung gegen generative KI so groß, dass schon kleine Fehler sofort als „AI-Schrott“ abgetan werden. Dabei ist das hier nur eine Demo und ein Proof of Concept

• Dieses Projekt soll den Linux-Kernel, QEMU, FFmpeg, Redis und sogar Doom bauen können. Das ist wirklich erstaunlich.
  Solche Agentensysteme funktionieren aber gut in testbaren Bereichen, haben jedoch Grenzen in Bereichen, die Kontext erfordern, etwa bei geschäftlichen Entscheidungen

  • Ich frage mich, ob der Begriff „Cleanroom-Implementierung“ für ein Modell, das bereits auf dem gesamten Internet trainiert wurde, überhaupt sinnvoll ist
  • Der nächste Schritt ist, dass KI echten Geschäftskontext versteht und operativ damit arbeitet. Wenn man sich Benchmarks wie Vending-Bench ansieht, dürfte der Tag nicht mehr fern sein, an dem ein KI-Produktmanager automatisch Nutzerinterviews, Experimente und Roadmap-Vorschläge durchführt

• Tolles Projekt, aber den Verweis auf „Cleanroom“ hätte man besser weggelassen. Es ist ein mit urheberrechtlich geschütztem Code trainiertes Modell und damit eher das Gegenteil

  • Andererseits lernen auch Menschen aus bestehenden Codebasen und erstellen auf dieser Grundlage Cleanroom-Implementierungen
  • So wie Menschen Wissen, das sie in einem Unternehmen erworben haben, anderswo wiederverwenden, rekonstruiert auch ein LLM seine Trainingsdaten auf transformative Weise. Solange es nicht direkt kopiert, ist die Lage anders

• Laut dem GitHub-Issue lag das Problem an einem fehlenden Include-Pfad. Mit dem Compiler selbst sei alles in Ordnung

  • Offenbar fehlte einfach ein Paket wie glibc-devel
  • Der Text war viel zu lang und hatte zu wenig Belege. Es fühlte sich an, als hätte er den Kern verfehlt
  • KI ist die Zukunft
  • Wirklich ein erstaunliches Ergebnis

• Ich würde mir wünschen, dass alle Prompts und die Agentenstruktur veröffentlicht werden. Zum Lernen wäre das großartig, aber zur Reproduktion selbst 20.000 Dollar auszugeben, ist eine hohe Hürde

  • Schade, dass man sich heute oft nur das Ergebnis ansieht und sich nicht mehr für den Prozess interessiert

• Das ist wie eine funktionierende Version des Cursor-Blogs. Der Nachweis, dass tatsächlich der Linux-Kernel gebaut wurde, ist deutlich überzeugender

  • Ursprünglich wollte ich zum 1. April nur eine leichte Sprache zum Spaß bauen, aber wenn jetzt Ergebnisse auf diesem Niveau herauskommen, ist das erstaunlich. Ich werde es trotzdem weiter versuchen

• Das ist ein Ansatz nach dem Muster: „Man kann Pyramiden bauen, aber keine Kathedralen“ (passender Beitrag).
  Es wurde eine enorme Menge Rechenleistung hineingesteckt, um die Funktionalität gewaltsam zu erreichen, und man könnte sagen, dass dabei 20.000 Dollar verbrannt wurden.
  Lineare Ergebnisse durch exponentiellen Compute-Einsatz zu erzielen, hat zwar Bedeutung, wirkt langfristig aber wie eine ineffiziente Richtung

  • Die 20.000 Dollar beziehen sich auf die API; als Abo entspräche das wohl nur fünf bis sechs Max-Plänen
  • Trotzdem entspricht das nur den Personalkosten eines FAANG-Ingenieurs für zwei Wochen. Ein Mensch kann in zwei Wochen keinen Compiler bauen, also hat das als Demonstration durchaus Wert