Auf einem Desktop-Rechner mit i7-Prozessor und 64 GB Arbeitsspeicher läuft ein Zähler hoch, der die Zahl der gleichzeitig arbeitenden Software-Agenten anzeigt. Bei 218 bleibt er stehen. Niemand greift in diesem Moment ein, niemand nickt Änderungsvorschläge ab, niemand ruft einen der Arbeiter zur Seite.
Was in der Nacht zum 2. September ablief, hat Teknium, der Entwickler hinter Hermes Agent, später selbst als eine der ungewöhnlichsten Aufräumaktionen beschrieben, die er je angestoßen hat. Hermes Agent ist der quelloffene Agent des Forschungsteams Nous Research. Sein Repository war über Jahre gewachsen wie ein Altbau, in dem immer wieder neue Wände eingezogen wurden, bis niemand mehr sicher sagen konnte, welcher Raum wozu gehört: mehr als eine Million Zeilen Python ohne Tests, eine einzelne Datei mit 34.847 Zeilen. Solche Gebäude funktionieren, aber jede Reparatur dauert länger als nötig, weil man zuerst den Grundriss suchen muss. Interessant ist am Ende weniger die Zahl 218 als die Rechnung, die dabei herauskommt.
Warum das Aufräumen jahrelang liegen blieb
Ein Refactoring dieser Größenordnung steht in Konkurrenz zu dem, was Nutzer sofort spüren. Teknium rechnet vor, dass ein kleines Team für dieselbe Arbeit zwei Monate bis zwei Jahre gebraucht hätte, mit geschätzten Personalkosten zwischen 150.000 und 1,8 Millionen Dollar. Solche Zahlen lassen sich schwer rechtfertigen, solange im selben Zeitraum Features und Bugfixes ausgeliefert werden sollen. Also blieb der Altbau stehen, und alle Beteiligten lernten, sich darin einzurichten.
Entscheidend war etwas anderes, und das gilt für jeden, der KI-Agenten für Code-Refactoring einsetzt. Teknium nutzt Hermes Agent täglich, um Hermes Agent weiterzuentwickeln. Dabei entsteht ein Kreislauf: Wenn ein Vorgehen funktioniert oder er den Agenten korrigiert, notiert dieser die Lektion und schreibt sie in seine Skills – lesbare Markdown-Dokumente mit Referenzdateien und Skripten, die er bei späteren Aufgaben wieder lädt. Der Agent merkt sich mit der Zeit, wie dieser eine Auftraggeber seine Arbeit haben will. Als der große Auftrag formuliert wurde, waren seine Standards längst hinterlegt, bis hin zu der Regel, einen fehlschlagenden Test erst auf unverändertem Code zu wiederholen, um zu prüfen, ob der Fehler schon vorher existierte.
Ein einziger Auftrag statt hundert Einzelbriefings
Die Anweisung fiel erstaunlich knapp aus und wurde über den Befehl /goal abgesetzt, der dem Agenten ein dauerhaftes Ziel gibt und ihn zum Weiterarbeiten auffordert, wenn er sonst anhalten würde. Teknium verlangte eine radikale Vereinfachung: mindestens 30 Prozent weniger Code, aufgeteilte Riesendateien, vereinheitlichte Hilfsfunktionen, weniger verschachtelte if/elif-Ketten, mehr Lesbarkeit. Ausdrücklich verbot er, auf Entscheidungen des Menschen zu warten – der Agent sollte liefern, nicht fragen.
Eine Aufgabenliste sagt genau, wo geschraubt werden soll, und scheitert, sobald die Lage vor Ort anders aussieht als geplant. Eine Zielvorgabe beschreibt einen Zustand, und der Ausführende entscheidet selbst, wie er dorthin kommt. Der gesamte Auftrag lag in einem Prompt, ergänzt um gespeichertes Wissen aus Monaten gemeinsamer Arbeit. Der Agent musste also nicht herausfinden, was guter Code für dieses Projekt bedeutet – er wusste es bereits.
Wie 1.393 Subagenten sich selbst organisiert haben
Der Hauptlauf dauerte etwa neunzehn aktive Stunden und schickte 1.393 Subagenten los, von denen bis zu 218 gleichzeitig arbeiteten. Der übergeordnete Agent bearbeitete keine Quelldatei selbst, sondern vermaß die Codebasis, teilte sie in 36 überschneidungsfreie Gruppen und schrieb für jede eine Arbeitsanweisung, die genau benannte, was zu vereinfachen war und welche Schnittstellen erhalten bleiben mussten. Einige Arbeiter delegierten Teile ihres Auftrags weiter, sodass der Baum drei Ebenen unter den ursprünglichen Agenten reichte.
Technisch lief das Ganze in einem einzigen Python-Prozess auf einem Arbeitsplatzrechner; nur die Werkzeuge starteten als lokale Subprozesse, während die Inferenz über ein externes Modell kam. Jeder Arbeiter bekam über git worktrees eine eigene Auskopplung des Repositories, damit sich die Änderungen nicht gegenseitig überschrieben. Vergleiche mit dem Original hielten die Qualität: Ein JSON-Schema eines Werkzeugs musste identisch bleiben, die Hilfe-Ausgabe eines Kommandozeilenbefehls ließ sich Byte für Byte prüfen. Nach jedem verifizierten Schritt wurde committet. Das sollte später wichtig werden.
Wo der Lauf beinahe gescheitert wäre
Nach etwa fünfzig Minuten lief das Authentifizierungstoken des Anbieters ab, und die daraus entstehenden Fehler beendeten den Lauf. Die bereits geschriebenen Commits und Arbeitsanweisungen überlebten, sodass keine Arbeit verloren ging. Teknium startete eine separate Hermes-Sitzung, ließ den Fehler diagnostizieren, packte das Ergebnis in eine Übergabe und reichte sie an die fortgesetzte Sitzung weiter. Die Arbeiter gingen daraufhin zurück in ihre gespeicherten Änderungen, reparierten unfertige Auslagerungen und machten weiter.
Beim Zusammenführen zeigte sich, warum automatisierte Code-Optimierung mit KI-Agenten ohne Kontrolle nicht funktioniert. Zwei Runden Community-Review fingen Regressionen, die die vorhandenen Tests übersehen hatten: Arbeiter hatten öffentliche Namen entfernt, weil innerhalb des Repositories niemand sie mehr aufrief – externe Plugins importierten sie jedoch. Eine automatische Umschreibung von suppress()-Aufrufen veränderte zudem die Fehlerbehandlung an rund 65 Stellen. Solche Funde zeigen vor allem, dass Tests nicht alles abdecken. Nach dem Merge folgten weitere Korrekturen.
Was die Zahlen zeigen – und wo neue Kosten entstehen
Der Vergleich vorher und nachher ist deutlich. Der Python-Code ohne Tests schrumpfte von 1.063.826 auf 698.363 Zeilen, also um 34,4 Prozent. Die Zahl der Dateien über 5.000 Zeilen sank von 37 auf 6, die Zahl der Funktionen über 300 Zeilen von 192 auf 2. Die längste if/elif-Kette kam von 92 auf 9 Zweige, und gateway/run.py, das größte Einzelstück, fiel von 34.847 auf 5.512 Zeilen.
Ob ein leichter lesbarer Bauplan auch für Agenten günstiger ist, prüfte das Team, indem es dieselben 4.000 Symbole in beiden Versionen nachschlagen ließ. Der durchschnittliche Token-Aufwand pro Nachschlagen fiel von 2.218 auf 993, und die Fälle, die ein zweites Lesefenster brauchten, gingen von 628 auf 184 zurück. Ein kurioser Nebenbefund: Der Median stieg, weil in einem festen Zeilenfenster nun dichterer Code steht – weniger Kommentare, weniger Dokumentationszeilen. Der Durchschnitt sank nur, weil die sehr großen Definitionen verschwanden. Nebenbei entstanden neue Kosten: mehr Module, mehr Importabhängigkeiten, längere Startzeiten einzelner Einstiegspunkte. Sechs Dateien liegen weiterhin über 5.000 Zeilen, und die Kopplung zwischen den Teilen hat der Umbau nicht aufgelöst. Aufräumen verschiebt Aufwand, es beendet ihn nicht.
Was das für Teams bedeutet
Die Kosten des Hauptlaufs lagen bei rund 19.300 Dollar an Modellaufrufen, inklusive der Folgesitzungen bei etwa 25.000 Dollar – ohne die Zeit für menschliches Review. Der geschätzte Aufwand für Handarbeit lag zwischen 150.000 und 1,8 Millionen Dollar. Das entspricht grob einem Prozent der Kosten und der Zeit, die sonst nötig gewesen wären. Gleichzeitig brachte der Lauf Verbesserungen an Hermes selbst hervor: Rund dreißig parallel gestartete Kopien des Sprachservers Pyright hatten 8,7 GB belegt, bis ein geteilter Server mit laufender Prüfung eingerichtet wurde. Doppelte HTTP-Transporte wurden entfernt, Referenzen auf beendete Agenten gelöscht.
Das Repository erhielt Regeln zu Dateigröße und Funktionskomplexität, aufgeteilt nach Bereichen, damit neue Arbeiter nur die relevanten Vorgaben laden. Ein zusätzlicher Test markiert entfernte öffentliche Namen, damit künftig keine Plugin-Schnittstelle mehr unbemerkt verschwindet. Die Skills des Entwicklers wurden während des Laufs automatisch um die gesammelten Lehren ergänzt, und er gibt sie an sein Team weiter; deren Agenten erben die Prozeduren, ohne die Sitzungen wiederholen zu müssen.
Was hier beschrieben wird, ist kein Werkzeug, das man einmal einschaltet. Es ist ein Gedächtnis, das man über Monate füttert. Der Agent war nur deshalb in der Lage, 1.393 Subagenten sinnvoll zu steuern, weil er den Auftraggeber, dessen Standards und die Fallstricke dieses einen Projekts bereits kannte. Wer Softwareentwicklung mit KI-Agenten beschleunigen will, sollte deshalb zuerst in diese Gewohnheit investieren: Fehler benennen, Vorgehen bestätigen, Lektionen festhalten. Dann beginnt der nächste Umbau mit dem Wissen des vorigen.
Quelle: nousresearch.com
