00:00:00Anthropic hat gerade etwas Gigantisches vollbracht: Sie haben 16 Claude-Agenten darauf angesetzt,
00:00:05einen C-Compiler zu entwickeln. Nach zwei Wochen Dauerbetrieb entstand tatsächlich ein Tool, das
00:00:11den Linux-Kernel kompilieren und sogar Doom ausführen konnte. Das ist extrem beeindruckend und war
00:00:16mit den älteren Versionen von Opus 4 definitiv noch nicht möglich. Doch viele bezeichnen das Ganze als Clickbait
00:00:22und Halbwahrheit, da Anthropic fragwürdige Techniken nutzte, um dieses Ergebnis zu erzielen.
00:00:28Hat Anthropic also geschummelt? Abonniert den Kanal und finden wir es heraus.
00:00:31Wir teilen dieses Video in drei Teile. Zuerst schauen wir uns den Versuchsaufbau an,
00:00:37dann gehen wir die wichtigsten Erkenntnisse durch, von denen jeder Entwickler profitieren kann,
00:00:42und am Ende klären wir, ob die Ergebnisse valide sind. Ich habe nämlich eine klare Meinung dazu,
00:00:47wie Anthropic diesen Compiler gebaut hat. Dieses Experiment wurde von Nicholas Carlini durchgeführt,
00:00:52einem meiner Meinung nach extrem klugen Kopf. Schauen wir uns mal an, wie er das
00:00:58aufgesetzt hat: Das eigentliche Projekt lag in einem Verzeichnis namens "Upstream", das
00:01:03in 16 verschiedene Docker-Container gemountet war. Hier sieht man nur vier, aber stellt euch 16 vor.
00:01:08Jeder dieser Container enthielt eine Version von Claude Code, die mit Opus 4.6 lief.
00:01:15Sie klonten das Upstream-Repo in einen Workspace, nahmen dort Änderungen vor und
00:01:21pushten diese zurück nach Upstream. Das war sehr clever, da jeder Agent isoliert arbeiten konnte,
00:01:27ohne die anderen zu stören. Falls es zu Merge-Konflikten kam, war Claude schlau genug,
00:01:32diese selbstständig zu lösen. Jeder Agent suchte sich Aufgaben aus einer Liste.
00:01:38Ich bin nicht sicher, ob diese Aufgaben von einem Menschen oder durch automatisierte Tests
00:01:44vom Agenten selbst erstellt wurden, aber es gab benannte Aufgaben, die nacheinander abgearbeitet wurden.
00:01:50Sobald ein Agent eine Aufgabe übernahm, startete er eine neue Session. Um den Prozess dauerhaft
00:01:56am Laufen zu halten, wurde eine Ralph-Schleife genutzt: Die Agenten erledigten eine Aufgabe,
00:02:02pushten das Ergebnis, starteten eine frische Session für die nächste Aufgabe und so weiter.
00:02:08Falls ihr unser Video über Ralph gesehen habt, wisst ihr: Der Schlüssel für langlebige Agenten
00:02:13sind klar definierte Aufgaben. Aber wie verhindert man bei 16 Agenten, dass zwei dieselbe Aufgabe wählen?
00:02:19Durch "Task-Locking". Das funktioniert so: Es existiert eine Liste von Aufgaben, und sobald
00:02:24ein Agent eine auswählt, erstellt er eine Textdatei mit dem Namen dieser Aufgabe.
00:02:30Er erzeugt einen Commit, um die Aufgabe zu sperren, und pusht diesen in das Upstream-Verzeichnis.
00:02:36Versucht ein anderer Agent dieselbe Aufgabe zu wählen und dieselbe Textdatei zu erstellen,
00:02:42wird der Push von Git abgelehnt, da die Datei bereits existiert. Der Agent muss sich dann
00:02:48eine andere Aufgabe suchen. Das war das Grundgerüst, mit dem Carlini die Belastbarkeit
00:02:53der Opus 4.6-Agenten getestet hat – und die Ergebnisse sind wirklich beeindruckend.
00:03:00Dabei hat er einige interessante Entdeckungen gemacht, von denen jeder Entwickler lernen kann.
00:03:07Der erste Punkt: Baut ein Test-Harness oder ein Skript, das verschiedene Testarten ausführt.
00:03:12Denn während des Experiments – Nick und ich sind mittlerweile per Du – stellte er fest,
00:03:17dass Claude oft bestehende Funktionen zerstörte, während an neuen gearbeitet wurde.
00:03:23Also baute er ein Test-Harness mit hochwertigen Tests aus bekannten Open-Source-Projekten
00:03:29wie SQLite, libjpg und Redis. Um den Kontext nicht zu überladen, filterte er die Ausgabe,
00:03:35sodass der Agent nur relevante Fehlerlogs sah. Alle anderen Logs landeten in einer separaten Datei,
00:03:41in die Claude bei Bedarf hineinschauen konnte. Bei tausenden von Tests hätte es jedoch
00:03:47Stunden gedauert, bis ein Agent fertig gewesen wäre – wertvolle Zeit, die verloren ginge.
00:03:52Hier wurde Nick kreativ: Er fügte dem Test-Harness einen "Fast-Flag" hinzu.
00:03:58Dadurch führte jeder Agent nur 1 % oder 10 % der Tests aus. Wenn jeder Agent 10 % prüft,
00:04:05entspricht das insgesamt 160 % Abdeckung – was absolut kein Nachteil ist.
00:04:13Das Ganze funktionierte so: Die spezifischen Tests für jeden Agenten wurden zwar
00:04:19per Zufall ausgewählt, aber der Seed-Wert war identisch, was das Ganze deterministisch machte.
00:04:25So bearbeitete jeder Agent zwar dieselben zufälligen Tests, ging aber das gesamte Test-Set
00:04:31viel schneller durch, als wenn er alles alleine hätte prüfen müssen.
00:04:36Der nächste Punkt ist ebenfalls clever, aber etwas umstritten: Bestehende Technik nutzen.
00:04:41Bisher hatten die Agenten Unit-Tests aus Open-Source-Projekten in kleinen Häppchen abgearbeitet.
00:04:46Doch beim Kompilieren des Linux-Kernels wurde es schwierig, da es sich hier nicht um
00:04:53einzelne Unit-Tests handelt. Jeder Agent versuchte, das Ganze zu kompilieren, stieß auf denselben Fehler
00:04:58und versuchte ihn zu beheben, wodurch sie sich gegenseitig die Korrekturen überschrieben.
00:05:04Nick löste das, indem er jeden Agenten nur einen Teil der Kompilierung durchführen ließ,
00:05:09während GCC – der bewährte GNU-Compiler – den Rest übernahm.
00:05:15Nick nannte GCC das "Orakel", da der Linux-Kernel damit perfekt kompilieren sollte.
00:05:22Wenn ein Agent also seinen Teil mit dem eigenen Compiler prüfte und den Rest mit GCC,
00:05:27war bei einem Fehler sofort klar: Es liegt am eigenen Compiler, nicht an GCC.
00:05:34So konnte der Agent gezielt den eigenen Fehler beheben, statt Bugs anderer Agenten zu jagen.
00:05:40Das ist deshalb umstritten, weil ein existierender Compiler für eine Aufgabe genutzt wurde,
00:05:46die Claude eigentlich komplett eigenständig lösen sollte. Darauf kommen wir gleich zurück.
00:05:51Kommen wir zum nächsten Punkt: Gebt euren Agenten ein Gedächtnis.
00:05:57Da jede neue Aufgabe in einer frischen Claude-Session ohne Vorwissen startete,
00:06:03aktualisierte Nick kontinuierlich die Readme-Datei und führte Fortschrittsdateien mit Anweisungen.
00:06:09So wussten neue Sessions genau, wo sie ansetzen mussten und bauten keine alten Fehler wieder ein.
00:06:13Der letzte, offensichtliche Punkt: Verteilt unterschiedliche Rollen.
00:06:18Der Vorteil paralleler Agenten ist, dass sie gleichzeitig verschiedene Dinge am selben Code tun können.
00:06:23Wenn kein neuer Code geschrieben wurde, gab Nick den Agenten spezialisierte Rollen:
00:06:29Einer suchte nach doppeltem Code, ein anderer optimierte die Performance,
00:06:35und einer kritisierte das Design aus der Sicht eines Rust-Entwicklers – von dem ich hoffe,
00:06:40dass er es den anderen Agenten nicht ständig unter die Nase gerieben hat.
00:06:45Doch bei allem Erfolg bleibt die Frage: Hat Anthropic geschummelt?
00:06:51Nun ja, irgendwie schon. Die Aufgabe war, einen C-Compiler von Grund auf zu bauen.
00:06:57Die Agenten hatten keinen Internetzugang, also schrieben sie den Code selbst – theoretisch.
00:07:03Aber sie hatten Zugriff auf die Test-Suiten von Open-Source-Projekten und auf den fertigen GCC.
00:07:10Technisch gesehen konnten sie GCC also mit Inputs füttern, die Outputs analysieren und
00:07:16dies als Vorlage für das Design ihres eigenen, in Rust geschriebenen Compilers nutzen.
00:07:24Fairerweise muss man sagen: Wenn ich einen C-Compiler bauen müsste, würde ich es genauso machen.
00:07:31Ich würde mir bestehende Lösungen ansehen und mich an deren Umsetzung orientieren.
00:07:36Wäre es eine völlig neue Programmiersprache gewesen, sähe die Sache anders aus.
00:07:41Das wäre vielleicht ein guter Test für Claude, um zu sehen, wie kreativ die KI wirklich ist.
00:07:47Vielleicht eine Idee für Nicks nächstes Experiment. Reden wir über die Autonomie.
00:07:53Claude hat zwar den gesamten Code geschrieben, aber unter starker Anleitung durch einen Menschen.
00:07:57Ein Mensch wählte die Tests aus, startete die Schleifen und entschied sich für das System.
00:08:04Ein Mensch baute das Test-Harness und verteilte die Rollen. Das ist weit entfernt davon,
00:08:11dass man Claude einfach sagt: "Bau einen Compiler" und dann weggeht.
00:08:16Ich würde nicht sagen, dass der Agent zu 100 % autonom war. Wie gut wäre das Ergebnis
00:08:22ohne menschliche Steuerung wohl gewesen?
00:08:28Selbst mit diesem menschlichen Framework hatte der Claude-Compiler deutliche Schwächen.
00:08:33Zum Beispiel nutzte er Assembler und Linker von GCC, da die eigenen Versionen zu fehlerhaft waren.
00:08:39Auch für den Linux-Bootvorgang wurde der 16-Bit-x86-Compiler von GCC benötigt.
00:08:46Zudem war der Code nicht sehr effizient: Selbst die optimierteste Version des Claude-Compilers
00:08:54war langsamer als die am wenigsten optimierte Version von GCC.
00:09:00Es sieht also so aus, als ob wir Entwickler vorerst noch gebraucht werden.
00:09:05Zumindest für den Moment.