From Translation to Superset: Benchmark-Driven Evolution of a Production AI Agent from Rust to Python

Dit paper beschrijft een benchmark-gedreven methode waarbij een LLM een productie-AI-agent succesvol van Rust naar Python vertaalt, wat resulteert in een beknoptere codebasis met vergelijkbare prestaties en een uitgebreidere functionaliteit.

De kern

Stel je voor dat je een zeer complexe, dure machine hebt gebouwd van Rust (een taal die bekend staat om zijn veiligheid en snelheid, maar ook om zijn strenge regels en moeilijkheid). Deze machine, genaamd CODEX CLI, is een slimme robot die voor programmeurs werkt: hij schrijft code, lost problemen op en voert commando's uit op een computer.

Nu wil het team van JPMorgan Chase deze machine niet meer in die strenge taal houden. Ze willen hem herschrijven in Python (een taal die veel populairder, flexibeler en makkelijker te leren is).

Het probleem? Normaal gesproken is het overschrijven van zo'n enorme machine (648.000 regels code!) een nachtmerrie. Het is als het proberen te vertalen van een hele bibliotheek van één taal naar een andere, terwijl de originele bibliotheek elke dag nieuwe boeken toevoegt. Als je dat één keer doet, loop je vaak vast, en als de originele machine verandert, moet je alles opnieuw doen.

Dit paper beschrijft hoe ze dit op een slimme, nieuwe manier hebben aangepakt. Hier is de uitleg in gewone taal:

1. De Vertaler is een AI, geen Mens

In plaats van dat honderden programmeurs maandenlang handmatig elke regel code vertalen, hebben ze een Grote Taalmodel (LLM) ingezet als vertaler. Dit is alsof je een super-intelligente tolk hebt die de hele machine in één keer kan "vertalen" van Rust naar Python.

Maar een tolk kan fouten maken. Hoe weet je of de nieuwe machine werkt?

2. De "Proefexamen"-Methode (Benchmarks als Doel)

Normaal gesproken testen programmeurs hun werk met kleine, specifieke tests (zoals: "werkt deze knop?"). Maar voor een complexe robot is dat niet genoeg. Je moet kijken of hij de hele taak kan uitvoeren.

De auteurs gebruikten publieke proefexamens (zoals Terminal-Bench en SWE-bench). Dit zijn sets van echte, moeilijke taken die de robot moet oplossen.

• De analogie: Stel je voor dat je een nieuwe auto bouwt. Je test niet alleen of de lichten werken (unit tests), maar je laat de auto een echte rallyrace rijden. Als de auto de race wint, weet je dat hij goed is.
• Het resultaat: De nieuwe Python-versie deed het bijna net zo goed als de oude Rust-versie. Op sommige testen was hij zelfs iets beter! Dit bewijst dat de "AI-vertaling" succesvol was.

3. Van "Kopie" naar "Super-App"

Het mooiste deel van dit verhaal is dat ze niet stopten bij "het werkt hetzelfde". Omdat Python makkelijker is om mee te werken, konden ze de nieuwe machine verbeteren terwijl ze hem vertaalden.

• De analogie: Stel je voor dat je een oude, betrouwbare benzineauto (Rust) vertaalt naar een elektrische auto (Python). Je bouwt hem niet alleen om, je voegt er ook een zelfrijdende functie, een koelkast en een stemassistent aan toe die de oude auto niet had.
• Het resultaat: De Python-versie heeft nu 30 extra functies (zoals het kunnen werken met meerdere robots tegelijk, het onthouden van gesprekken, en veiligheidscontroles) die de originele Rust-versie niet heeft. Ze noemen dit een "Superset": alles wat de oude had, plus meer.

4. De Levende Brug (Continue Synchronisatie)

Omdat de originele Rust-machine elke dag updates krijgt, zou de Python-versie snel verouderd zijn. Maar het team bouwde een automatische brug.

• Hoe het werkt: Als er een verandering komt in de Rust-code, pakt een script die verandering, laat de AI die vertalen, en test het direct met de "proefexamens". Als het goed werkt, wordt het toegevoegd.
• De analogie: Het is alsof je een levende vertaling hebt van een nieuwswebsite. Zodra er een nieuw artikel in het origineel verschijnt, wordt het direct vertaald en gepubliceerd, zonder dat iemand handmatig hoeft te typen.

5. Waarom Python? (De Snelheid van de Robot)

Je zou denken: "Rust is sneller, waarom Python?"

• De ontdekking: Voor deze specifieke robot is de "snelheid" van de computer zelf niet het probleem. Het probleem is dat de robot moet wachten op een antwoord van een andere AI (de "hersenen"). Die wachttijd duurt 1 tot 10 seconden.
• De vergelijking: Het maakt niet uit of de robot 0,01 seconde of 0,1 seconde doet over een lokale taak; hij staat toch al 10 seconden stil te wachten op de AI.
• Het voordeel: Python is veel korter (15 keer minder code!) en makkelijker te lezen. Dit betekent dat de robot lichter is, makkelijker te onderhouden is en dat meer mensen er aan kunnen werken.

Samenvatting in één zin

Dit paper laat zien dat je met de hulp van AI een enorme, complexe softwaremachine van een strenge taal (Rust) naar een flexibele taal (Python) kunt verplaatsen, niet alleen door het te kopiëren, maar door het te verbeteren en te koppelen aan echte "proefexamens" om te garanderen dat het werkt, waardoor je uiteindelijk een krachtigere machine krijgt dan je ooit had.

Technische samenvatting

Probleemstelling

De migratie van grote softwaresystemen tussen programmeertalen is een aanhoudende uitdaging in de software-engineering. Traditionele migraties zijn vaak eenmalige, arbeidsintensieve en foutgevoelige projecten. Zodra de migratie voltooid is, divergeren de bron- en doelsystemen permanent; verbeteringen in de oorspronkelijke taal (in dit geval Rust) moeten handmatig worden overgebracht of worden verwaarloosd. Dit is vooral problematisch voor snel evoluerende projecten waar de upstream dagelijks updates levert.

Het paper richt zich op CODEX CLI, een productieve AI-coderingsagent die oorspronkelijk was geschreven in Rust (648.000 regels code, 65 crates). De auteurs wilden migreren naar Python om te profiteren van snellere iteratie, betere integratie met het AI/ML-ecosysteem en een lagere drempel voor bijdragers, maar zonder de functionaliteit te verliezen of de onderhoudskosten te verhogen.

Methodologie: Benchmark-gedreven Evolutie

De kern van de voorgestelde methologie is het gebruik van LLM-assisterende continue code-vertaling, waarbij publieke agent-benchmarks fungeren als de objectieve functie (loss function) voor iteratieve verbetering. In plaats van alleen te vertrouwen op statische tests, sturen de resultaten van real-world taken de correctie van de vertaling.

1. LLM als Vertaalmotor: Een Large Language Model (LLM) vertaalt de Rust-code naar Python, maar met de instructie om idiomatische Python te genereren (bijv. Result<T,E> naar uitzonderingen, Tokio naar asyncio, serde naar Pydantic) in plaats van mechanische transpilatie.
2. Benchmark als Objectieve Functie: De auteurs gebruiken Terminal-Bench (80 complexe terminal-taken) en SWE-bench Verified (80 software-engineering taken) om de correctheid te valideren. Fouten in deze benchmarks (zoals API-protocolmismatches of omgevingsproblemen) worden gebruikt om de vertaling iteratief te verbeteren.
3. Continue Synchronisatie: Een architectuur voor "levende migratie" is opgezet:
   • Track: De Rust-repo wordt gevolgd via een git-submodule.
   • Diff: Alleen gewijzigde modules worden geëxtraheerd.
   • Translate: Het LLM vertaalt alleen de diffs naar Python.
   • Validate: De vertaling wordt getest met unit-tests en benchmark-regressietests. Als de benchmark-score daalt, wordt de vertaling verfijnd.

Belangrijkste Bijdragen

1. Van Pariteit naar Superset:
   De Python-versie bereikte niet alleen functionele pariteit met de Rust-versie, maar evolueerde daarnaast tot een capaciteitssuperset. Via een codex.enhancements-module zijn 30 nieuwe, feature-gateerde functies toegevoegd die ontbreken in Rust, waaronder:

   • Multi-agent orkestratie.
   • Semantisch geheugen en persistente plannen.
   • Kostentracking en IDE-bruggen.
   • Guardian-veiligheidsbeoordeling en spraakmodus.
     Een flag-resolutiesysteem zorgt ervoor dat er een "strict parity mode" bestaat voor eerlijke vergelijkingen, terwijl de uitgebreide functies optioneel zijn.

2. Benchmark-gedreven Debugging:
   De studie toont aan dat benchmarks effectiever zijn dan statische tests voor het opsporen van integratiefouten. Unit-tests (2.621 stuks) slaagden direct, maar de agent faalde aanvankelijk volledig op Terminal-Bench (0% succes). Benchmark-runnen onthulde kritieke problemen zoals:

   • API-protocolmismatches (verkeerde JSON-types).
   • Omgevingsvervuiling door pip-installaties.
   • Stille WebSocket-fouten (lege antwoorden die als succes werden gemarkeerd).
   • Invalid content-item types die de agent deden crashen.

3. Architectuur voor Continue Upstream-sync:
   Het paper beschrijft een robuust systeem dat het Python-port in staat stelt om dagelijkse commits uit de Rust-upstream automatisch op te vangen en te vertalen, waardoor de kloof tussen de twee talen gesloten blijft.

Resultaten en Evaluatie

De evaluatie omvatte code-metrics, testpariteit, runtime-prestaties en head-to-head benchmarking.

• Code-reductie: De migratie resulteerde in een 15,9x reductie in codegrootte (van 648K LOC in Rust naar 41K LOC in Python, hoewel de tabel in het paper een totale reductie van 12,3x aangeeft voor de volledige codebase inclusief enhancements).
• Benchmark-resultaten:
  • Terminal-Bench: Python behaalde 42,5% (34/80 taken) versus Rust's 47,5% (38/80). Het verschil is klein en deels toe te schrijven aan niet-deterministisch LLM-gedrag en specifieke omgevingsfactoren.
  • SWE-bench Verified: Python behaalde 73,8% (59/80 taken) versus Rust's 70,0% (56/80), waarbij Python zelfs een licht voordeel liet zien.
• Prestaties:
  • De lokale Python-overhead (tool-uitvoering, sandboxing, policy-checks) is verwaarloosbaar (<25ms) vergeleken met de LLM-API-latentie (1-10 seconden per ronde).
  • De Python-agent voert lokale berekeningen 2 tot 6 ordes van grootte sneller uit dan de LLM-communicatie, wat betekent dat de taalkeuze geen prestatieknelpunt vormt voor dit type applicatie.
  • Cyclomatische complexiteit bleef hoog (90% van de functies behaalde rang A), wat aangeeft dat de code leesbaar en onderhoudbaar bleef.
• Foutoplossing: Tijdens het benchmarken werden bugs gevonden die ook in de Rust-versie zaten (zoals de WebSocket-lege-antwoord-fout), maar de Python-versie kreeg hierdoor een robuustere fallback-mechanisme (met 429-detectie en retry-after headers) dan de originele Rust-versie.

Betekenis en Conclusie

Dit paper demonstreert dat voor LLM-gedreven agenten, waar de prestaties worden gedomineerd door API-latentie, de expressiviteit en snelheid van Python de performance-voordelen van Rust ruimschoots compenseren.

De belangrijkste conclusies zijn:

1. Benchmarks boven tests: Voor complexe systeemtranslaties zijn publieke benchmarks essentieel als objectieve functie om integratiefouten te vinden die unit-tests missen.
2. Continue migratie: Vertaling moet een continu proces zijn, niet een eenmalige migratie, om de kloof met de upstream te dichten.
3. Taalkeuze volgt bottleneck: Voor I/O-gebonden AI-agenten is Python superieur vanwege de snellere ontwikkelingstijd en het ecosysteem, zonder merkbare prestatie-impact.
4. Vertaling als springplank: Een vertaalde port kan evolueren tot een krachtiger platform dan het origineel (een "superset"), waarbij nieuwe functies sneller kunnen worden geïmplementeerd en getest dan in de oorspronkelijke taal.

De methode biedt een principieel raamwerk voor het ontwikkelen van cross-language systemen die niet alleen functioneel equivalent zijn, maar ook kunnen uitgroeien tot eersteklas, uitgebreide platformen.