100.000 Zeilen TypeScript nach Rust: Praxisbericht über ein Porting mit Claude Code

Der ehemalige Facebook-Ingenieur Christopher Chedeau (Vjeux) hat in einem Experiment die Pokemon Showdown-Battle-Engine (ca. 100.000 Zeilen TypeScript) mithilfe von Claude Code nach Rust portiert.

Projektziel

• Aufbau eines schnellen Orakels (Referenzsystems) für das Training einer Pokemon-Battle-KI
• Bestehende TypeScript-Implementierung → zu langsam (Millionen von Battle-Simulationen nicht möglich)
• Zielsprache: Rust (hohe Performance) → jedoch selbst null Erfahrung mit Rust

Wichtigste Ergebnisse

• In 1 Monat (tatsächliche Arbeitszeit ca. 2–4 Wochen) rund 100.000 Zeilen portiert
• Etwa 5.000 Commits erzeugt
• Ausführungsgeschwindigkeit um das 3,5-Fache gesteigert
• Übereinstimmungsrate im Differentialtest von 99,96 % (auf Basis von 2 Millionen zufälligen Battles)
  • Die übrigen 0,04 % werden vermutlich durch Bugs im ursprünglichen TS-Code verursacht

Kernstrategie für den Erfolg

• Einführung von Differential Testing
  • TS-Original und Rust-Version gleichzeitig ausführen → Ergebnisse vergleichen
  • Bei Abweichungen → Claude die Logs zeigen und Korrekturen anweisen
• Verifikation war möglich, obwohl er die Rust-Syntax kaum kannte

Wichtigste Schwierigkeiten für Claude

• Das Portieren einzelner Dateien funktionierte gut ↔ bei der Integration zwischen Dateien traten häufig Probleme auf
  • Beispiel: Dasselbe Konzept (move) wurde als unterschiedliche Structs definiert
• Begrenztes Kontextfenster → im Verlauf von Zwischenzusammenfassungen gingen wichtige Informationen verloren
• Tendenz, Dinge „besser“ machen zu wollen → explizite Anweisung zum „Portieren Zeile für Zeile“ wurde ignoriert und stattdessen Refactoring versucht → viele Bugs produziert
• Optimierungsanfragen → die Pläne sahen großartig aus, brachten in der Praxis aber kaum Performance-Gewinne (teils wurden sie sogar langsamer)

Ungewöhnlicher Workflow-Hack

• Automatisierung von Claudes Anfragen nach Benutzerfreigaben
  • Mit AppleScript wurde alle paar Sekunden automatisch Enter gedrückt → 24 Stunden unbeaufsichtigter Betrieb
  • (Sicherheitsrisiko vorhanden, wurde aber für den einmaligen Oracle-Zweck in Kauf genommen)

Stand der AI-Coding-Tools (Einschätzung)

• Mechanische Umwandlungen und groß angelegte Portierungsarbeiten → sehr stark
• Höherwertige Aufgaben wie Performance-Optimierung oder Architekturdesign → noch unzureichend
• Debatte auf Hacker News
  • Skeptiker: nicht wartbar, Code, der „nur kompiliert“
  • Befürworter: mit Differential Testing ausreichend vertrauenswürdig + enorme Zeitersparnis gegenüber Menschen

3 Erkenntnisse für den Praxiseinsatz

• Ein gründliches automatisiertes Testsystem ist unverzichtbar (ohne Differential Testing ist die Wahrscheinlichkeit des Scheiterns sehr hoch)
• Klare und eng gefasste Anweisungen funktionieren am besten („Portiere Zeile für Zeile“ O vs. „Verbessere das“ X)
• AI ist nur ein Werkzeug → Entwickler müssen weiterhin Probleme diagnostizieren, Fragen formulieren und die Richtung vorgeben

→ Ein Fall, in dem jemand ohne jede Rust-Kenntnis Code im Umfang von 100.000 Zeilen in nur einem Monat auf ein praktisch nutzbares Niveau übertragen hat → ein repräsentatives Experiment, das die Praxistauglichkeit von AI-Coding belegt und zugleich seine Grenzen klar offenlegt

https://aisparkup.com/posts/8701

[ahwjdekf]

Dabei wird übersehen, dass das Schreiben von Testfällen kein Allheilmittel ist. Es geht nicht nur darum, dass Input und Output korrekt sind. Am Ende wird man die 100.000 Zeilen doch noch einmal überprüfen müssen.