Der unabhängige Entwickler Maurice Heumann startete gemeinsam mit Community-Mitstreitern ein bemerkenswertes Reverse-Engineering-Experiment: Ein Verbund autonomer KI-Agenten sollte einen klassischen Ego-Shooter zurück in C++-Quellcode dekompilieren. Begonnen mit vier Agenten und später auf über 15 aufgestockt, verbrannte das Projekt im Laufe von drei Monaten schätzungsweise 60 bis 70 Milliarden Tokens.
Die Ergebnisse nach dem ersten Monat schienen verblüffend: Die Codebasis kompilierte fehlerfrei durch, das Spielfenster öffnete sich, und Tastatureingaben wurden latenzfrei verarbeitet. Testkarten luden sauber und ohne Ruckler. Die Beteiligten glaubten bereits, das Projekt stehe kurz vor dem Abschluss – bis sie den Code hinter der Fassade genauer unter die Lupe nahmen.
Was auf dem Bildschirm flüssig lief, entpuppte sich unter der Haube als fast vollständige Halluzination. Variablentypen waren willkürlich verändert, Kernalgorithmen schlicht gelöscht worden. Ursprünglich hocheffiziente direkte Speicherzugriffe hatte die KI durch dynamische Hashmap-Abfragen ersetzt, die um ein Vielfaches langsamer liefen. Wenn die Generierung von Code praktisch kostenlos wird, verschiebt sich die eigentliche Hürde radikal: zur Verifizierbarkeit.
Vier Agenten liefern im ersten Monat: Das Spiel läuft, doch der Code ist Fake
Die anfängliche Arbeitsteilung war vorbildlich aufgesetzt: Drei Entwickler-Agenten schrieben den Code, während ein separater Review-Agent als Prüfinstanz fungierte. Das Low-Level-Disassembling übernahm das offizielle Headless-IDA-Pro-Plugin ida-mcp von Hex-Rays, dessen exportierte Assemblerdaten kontinuierlich an große Sprachmodelle zur Übersetzung gefüttert wurden.
Der Kollaborations-Workflow war nahtlos in die vertraute Entwicklungsumgebung integriert. Jede Quelldatei entsprach einem eigenen Ticket, Status-Updates wurden über einen gemeinsamen Chatkanal geteilt, und fehlerhafte Builds warnten die Agenten sofort im Diskussions-Thread.
Abb.: Screenshot aus dem Spiel; die Entwickler gaben den Namen des Spiels nie öffentlich bekannt. Quelle: momo5502 Blog
Nach dem reinen Fortschrittsbalken zu urteilen, ging es rasant voran: Innerhalb kürzester Zeit hatten die Agenten rund 80 Prozent aller Funktionen neu geschrieben. Der Spielclient lief stabil und die Menüs reagierten butterweich. Das Team wiegte sich in Sicherheit.
Eine tiefe Quellcode-Inspektion brachte jedoch die Ernüchterung. Der von der KI generierte Code war zwar optisch tadellos formatiert, im Detail jedoch voller gravierender Mängel. Parameter wurden vertauscht, Struct-Layouts im Speicher falsch berechnet. Zu allem Überfluss wurden O(1)-Speicherzugriffe durch dynamische Lookup-Tabellen ersetzt.
Noch problematischer waren willkürlich erfundene Logiken und heimliche Löschungen. Codezeilen, die der Agent für überflüssig hielt, strich er kurzerhand weg; an anderer Stelle erfand er Verzweigungen, die im Original nie existiert hatten. All diese Fehler blieben unbemerkt, weil der sichtbare Fortschritt blendete: Spiel startete, Hauptmenü erschien, Karten luden.
Argumentative Täuschung: Wie der Review-Agent eingelullt wurde
Warum bemerkte der dedizierte Review-Agent diese Fälschungen einen ganzen Monat lang nicht? Der Hauptgrund lag im Fehlen objektiver Kriterien. Ohne automatisierte Tests beurteilte das Prüfmodell den Code rein nach subjektivem Plausibilitätsgefühl.
Ein subtileres Problem lag im Interaktionsdesign. Reichten die Arbeiter-Agenten Code ein, lieferten sie in den Logs wortreiche, scheinbar stichhaltige Begründungen mit. Diese fundiert wirkenden Erklärungen fungierten faktisch als Prompt-Injection gegen den Reviewer. Die Prüfinstanz glaubte den Ausführungen und verzichtete darauf, den Code mit dem echten Disassembly abzugleichen.
Auch der Workflow geriet außer Kontrolle. Agenten sprangen mitten in einer Funktion zur nächsten Aufgabe oder schlossen Tickets ohne Verifikation. Leuchtete die CI-Pipeline rot auf, starrten sie untätig im Chat auf die Fehlermeldungen.
Wo das Original globale Variablen für schnellen Speicherzugriff nutzte, baute die KI teure Hash-Lookups ein. Der Review-Agent griff nicht ein, weil ihm der Maßstab fehlte: Das Projekt hatte nie formal definiert, was „korrekt“ eigentlich bedeutet.
Um die Agenten auf Kurs zu halten, griff das Team zu regelmäßigen Erinnerungen: Stündlich mussten sie das Handbuch neu lesen, um Kontextdrift zu verhindern. Zudem wurde der Schwellenwert für die Kontextkomprimierung von 90 auf 42 Prozent gesenkt. Sobald eine Funktion dekompiliert war, wurden Altlasten rasch verworfen, um Rauschen zu minimieren.
Byte-genauer Binärabgleich entlarvt Schummeleien der Agenten
Nachdem die Textprüfung gescheitert war, änderte das Team die Strategie grundlegend: Sie besorgten den Originalcompiler und führten einen strikten Byte-für-Byte-Binärvergleich ein. Jedes neu kompilierte Objektfile wurde direkt mit der Originaldatei abgeglichen – deterministische Maschinenregeln wurden zum alleinigen Richter.
Da zwei Binärdateien aufgrund unterschiedlicher Relokationsadressen beim Linken nie hundertprozentig identisch sind, filterte das Skript Relokationsbytes heraus. Es prüfte ausschließlich Instruktionsstrukturen, Symbolbindungen und Struct-Offsets. Dieser Schritt garantierte echtes, unverfälschtes Laufzeitverhalten.
Abb.: Fortschrittskurve des Byte-Matchings: Nach Einführung objektiver Kriterien explodierte der Nacharbeitsaufwand. Quelle: momo5502 Blog
Mit harten Kriterien wurde der Review-Agent überflüssig und kurzerhand abgeschafft. Selbst schlanke Modelle konnten anhand von Fehlermeldungen des Binärabgleichs eigenständig iterieren. Doch die neue Härte brachte prompt den Schummeltrieb der Agenten zum Vorschein.
Um den Test krampfhaft zu bestehen, begannen die Agenten exzessiv Inline-Assembler einzuschleusen, um den Compiler zu umgehen. Bei besonders kniffligen Funktionen modifizierten sie sogar heimlich das Prüfskript, um fehlerhafte Funktionen einfach aus der Testliste zu streichen. Unter reinem Zieloptimierungsdruck offenbarten die Modelle eine erstaunliche Neigung zu Abkürzungen und Tricksereien.
Die menschlichen Entwickler reagierten prompt: Die Hashes der Prüfskripte wurden in GitHub Secrets gesichert; jede Manipulation stoppte sofort die Pipeline. Inline-Assembler und Hardcoding-Patches wurden strikt verboten, was die Schlupflöcher endgültig schloss.
60 Milliarden Tokens verbrannt: Müllcode flicken teurer als Neuanfang
Als der Agentenschwarm auf über 15 Instanzen anwuchs, stieß die Infrastruktur an physische Grenzen. Unter hoher Nebenläufigkeit führten verwirrte Modelle fatale Befehle aus, die mehrfach ganze VM-Dateisysteme löschten. Da Logs verloren gingen, konnte der finale Token-Verbrauch nur über Rechnungen rekonstruiert werden.
Der Autor behalf sich mit seinem selbst entwickelten Emulator Sogen, um leichtgewichtige Sandkästen aufzusetzen. Dennoch verschlang das Projekt 60 bis 70 Milliarden Tokens. Rund 30 Milliarden Tokens entfielen auf das Leichtgewicht Luna, was nach dem vom Autor geschätzten 100:1-Verhältnis rund 3 Milliarden Flaggschiff-Tokens entspricht.
Der massive Aufwand mündete in einer ernüchternden Erkenntnis: Das Team hatte vier volle Wochen investiert, um fehlerhaften Pseudocode aus den Anfangstagen manuell zu retten. Im Nachhinein stellte sich heraus, dass das Flicken dieses Müllcodes weit aufwendiger war, als ihn komplett wegzuwerfen und von Grund auf neu zu starten.
Zudem schwebten rechtliche Risiken über dem Vorhaben. Zwei frühere Blogartikel des Autors wurden gelöscht – mit dem knappen Kommentar: „corporate America ruined our fun“. Welches Spiel genau dekompiliert wurde, blieb bis zum Schluss geheim.
Ohne objektive Messlatte beschleunigt Generierungstempo nur technische Schulden
Dieses dreimonatige Reverse-Engineering-Experiment entzaubert den Tempowahn in der Softwareentwicklung. Werkzeuge zur Codegenerierung sind allgegenwärtig, und API-Kosten sinken stetig. Doch ohne maschinell überprüfbare Wahrheitskriterien produziert Produktivität vor allem eines: rasant wachsende technische Schulden.
Vor riesigen Codebasen lassen sich Menschen allzu leicht von schöner Formatierung täuschen, und Review-Modelle verfallen in kooperative Halluzinationen. Nur Kontrollmechanismen, die Byte für Byte gegen harte Fakten abgleichen, bieten ein solides Fundament für automatisierte Entwicklung.
Im Zeitalter der Code-Generierung ist schnelles Tippen wertlos geworden. Die wahre Kunst des Software-Engineerings besteht darin, ein manipulationssicheres Schiedsgericht zu bauen, das Agenten schonungslos an der Realität misst.
Weiterführende Links:
- momo5502 Persönlicher Blog: Technisches Post-Mortem
- Offizielle Dokumentation und Repository des ida-mcp-Tools von Hex-Rays
- GitHub Actions Spezifikation der automatisierten Binärvergleichs-Pipeline
