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

Cette étude présente une méthodologie de migration assistée par LLM d'un agent de codage de production de Rust vers Python, démontrant que l'utilisation de benchmarks comme fonction objectif permet non seulement d'atteindre une parité de performance, mais aussi de transformer le portage en une plateforme étendue avec une réduction significative du code sans pénalité de performance.

L'essentiel

Imaginez que vous possédez une usine de fabrication de robots très sophistiquée, construite avec des briques de métal très solides mais lourdes et difficiles à modifier : c'est le Rust. Cette usine fonctionne parfaitement, mais elle est complexe, lente à construire et seule une poignée d'ingénieurs experts peut la réparer.

Les auteurs de ce papier (de JP Morgan) ont eu une idée géniale : traduire toute cette usine en briques de Lego, c'est-à-dire en Python. Le Python est plus léger, plus facile à manipuler et tout le monde sait jouer avec.

Voici comment ils ont fait, expliqué simplement :

1. Le Défi : Traduire sans casser le robot

Traduire un logiciel de cette taille (648 000 lignes de code !) est comme essayer de traduire un roman entier mot à mot sans changer le sens de l'histoire. D'habitude, on le fait une seule fois, et ensuite les deux versions s'éloignent l'une de l'autre.

Ils ont fait différemment. Ils ont utilisé une Intelligence Artificielle (LLM) comme traducteur principal, mais avec une astuce de maître : ils ont utilisé des examens pratiques pour vérifier si le robot fonctionne toujours aussi bien.

2. L'Élève modèle : Les "Examens" comme boussole

Au lieu de simplement vérifier si le code ressemble à l'original (comme vérifier l'orthographe), ils ont soumis le nouveau robot Python à de vrais défis :

• Terminal-Bench : Un jeu vidéo où le robot doit résoudre des énigmes complexes dans un terminal d'ordinateur.
• SWE-bench : Un examen de "réparation de code" où le robot doit corriger des bugs dans de vrais projets informatiques.

Le résultat est bluffant :

• Le robot en Rust (l'original) a réussi 70 % des exercices de réparation.
• Le robot en Python (le nouveau) a réussi 73,8 % !
• Sur les énigmes de terminal, le Python a fait 42,5 % contre 47,5 % pour le Rust. C'est presque pareil !

Cela prouve que le robot en Lego fonctionne aussi bien, voire mieux, que celui en métal.

3. La Méthode : Apprendre par l'échec

C'est ici que l'histoire devient intéressante. Au début, le robot Python ne fonctionnait pas du tout (0 % de réussite). Pourquoi ?

• Il parlait le mauvais langage à l'IA.
• Il se perdait dans son propre environnement.
• Il avait peur de certaines commandes.

Au lieu de relire tout le code à la main, les auteurs ont laissé le robot échouer sur les examens. Chaque fois qu'il échouait, l'IA a analysé pourquoi il a échoué et a corrigé le code spécifiquement pour ce problème. C'est comme un professeur qui ne vous donne pas la réponse, mais vous dit : "Regarde, tu as raté ce coup de pied, voici comment le faire la prochaine fois."

Grâce à cette méthode, ils ont trouvé des bugs invisibles que les tests classiques n'auraient jamais vus (comme un silence radio du robot quand il était fatigué).

4. La Surprise : Le robot Python est devenu un Super-Héros

Une fois que le robot Python a prouvé qu'il était aussi bon que le Rust, ils ne se sont pas arrêtés là. Ils ont commencé à lui ajouter des super-pouvoirs que l'ancien robot en métal n'avait pas :

• Orchestration multi-agents : Il peut maintenant diriger d'autres robots.
• Mémoire sémantique : Il se souvient mieux de ce qu'il a fait.
• Suivi des coûts : Il sait combien il coûte de l'utiliser.
• Mode voix : Il peut parler !

Ils ont ajouté 30 nouvelles fonctionnalités. Le plus génial ? Ils ont mis des interrupteurs. Si vous voulez comparer les deux robots "à égalité", vous éteignez les super-pouvoirs. Si vous voulez le robot ultime, vous les allumez.

5. Pourquoi changer ? (Le gain de temps)

Le code Python est 16 fois plus court que le code Rust pour faire la même chose.

• Analogie : Imaginez que le Rust est une encyclopédie de 10 volumes expliquant comment faire un sandwich. Le Python est une petite carte de recettes de 1 page.
• Performance : Comme le robot passe 99,9 % de son temps à attendre que l'IA (le cerveau) réponde (ce qui prend quelques secondes), le fait que le Python soit un peu plus lent à démarrer (quelques millisecondes) est totalement négligeable. C'est comme attendre un bus : peu importe si vous marchez 2 secondes de plus pour monter, le bus (l'IA) est le facteur limitant.

En résumé

Cette étude montre que :

1. On peut traduire des logiciels géants d'une langue à l'autre en utilisant l'IA et des examens pratiques pour guider le processus.
2. Le résultat n'est pas juste une copie, mais une version améliorée qui est plus facile à maintenir, plus courte et plus riche en fonctionnalités.
3. Pour les robots intelligents qui dépendent de l'IA, la vitesse du langage de programmation compte moins que la facilité à le faire évoluer.

C'est comme passer d'une voiture de course en métal lourd et complexe à une voiture électrique légère, rapide et modifiable, tout en gardant la même vitesse de pointe sur la route principale.

Résumé technique

Titre : De la Traduction au Sur-ensemble : Évolution Pilotée par les Benchmarks d'un Agent de Production de Rust vers Python

1. Problématique

La migration inter-langage de grands systèmes logiciels est un défi d'ingénierie persistant, particulièrement lorsque le code source évolue rapidement. Traditionnellement, ces migrations sont des efforts ponctuels, laborieux et sujets aux erreurs. Une fois la migration terminée, les deux bases de code (source et cible) divergent, rendant la synchronisation des améliorations ultérieures difficile.

Dans le contexte spécifique des agents de codage IA (LLM), où la latence de l'API LLM domine le temps de réponse global, l'objectif est de déterminer si un langage plus expressif et rapide à prototyper (Python) peut remplacer un langage axé sur la sécurité et la performance (Rust) sans sacrifier les performances fonctionnelles, tout en permettant une évolution continue du système.

2. Méthodologie

Les auteurs présentent une méthodologie de traduction de code assistée par LLM couplée à une validation par benchmark, appliquée à CODEX CLI, un agent de codage IA de production initialement écrit en Rust (648k lignes de code, 65 crates).

A. Traduction Assistée par LLM

• Approche : Au lieu d'une transpilation syntaxique, un LLM est utilisé pour traduire le code Rust en Python idiomatique.
• Mapping des Idioms : Le LLM convertit les patterns Rust vers leurs équivalents Python naturels (ex: Result<T, E> vers les exceptions, Tokio vers asyncio, serde vers Pydantic).
• Architecture : Le système est décomposé en 28 modules Python (contre 6 crates Rust), organisés en couches (Agent, Sécurité, Protocole, Intégration, Présentation, Infrastructure).

B. Le Benchmark comme Fonction Objectif

C'est le cœur de la contribution méthodologique. Les tests unitaires sont jugés insuffisants pour valider la traduction d'un système complexe.

• Benchmarks Utilisés : Terminal-Bench (80 tâches complexes d'opérations terminal) et SWE-bench Verified (80 tâches de résolution de bugs réels).
• Boucle de Raffinement : Les échecs sur les benchmarks révèlent des bugs d'intégration invisibles aux tests unitaires (mismatches de protocoles API, pollution d'environnement, modes d'échec silencieux). Chaque échec déclenche une itération de débogage et de correction par le LLM jusqu'à atteindre la parité.

C. Synchronisation Continue

Une architecture en quatre étapes permet de maintenir la parité avec le dépôt Rust amont qui évolue quotidiennement :

1. Suivi : Le dépôt Rust est suivi via un sous-module Git.
2. Diff : Extraction des modules modifiés.
3. Traduction : Le LLM traduit uniquement les diffs (et non tout le module) en utilisant le contexte Python existant.
4. Validation : Tests unitaires, vérification de type (mypy) et régression sur les benchmarks.

3. Contributions Clés

1. Méthodologie « Benchmark-as-Objective-Function » : Démonstration que les benchmarks publics d'agents sont des fonctions objectif supérieures aux tests unitaires pour guider la traduction inter-langage, révélant des bugs de protocole et d'environnement critiques.
2. Évolution vers un Sur-ensemble (Superset) : Le port Python n'est pas une simple réplique. Grâce au module codex.enhancements, il intègre 30 extensions (orchestration multi-agents, mémoire sémantique, suivi des coûts, mode vocal, etc.) absentes de la version Rust, tout en conservant un mode « parité stricte » via des drapeaux fonctionnels pour les comparaisons équitables.
3. Architecture de Synchronisation Continue : Un pipeline automatisé (diff-translate-test) permettant d'absorber les commits Rust quotidiens sans effort manuel massif.
4. Évaluation Empirique Complexe : Une analyse multidimensionnelle couvrant la complexité cyclomatique, la couverture de test, les performances d'exécution et les résultats de benchmarks tête-à-tête.

4. Résultats

A. Métriques de Code

• Réduction de taille : Passage de 648k lignes (Rust) à 41k lignes (Python), soit une réduction de 15,9x.
• Complexité : 90% des fonctions Python atteignent le rang A de complexité cyclomatique (faible complexité).
• Tests : 2 902 fonctions de test en Python (vs 8 490 en Rust), avec un ratio de 62 tests par KLOC, couvrant les contrats comportementaux plutôt que les invariants de mémoire.

B. Performances d'Exécution

• Latence Locale : Le temps de démarrage est légèrement plus lent (53,9 ms vs binaire Rust), mais cela représente < 0,1% du temps total d'une session d'agent (dominé par les appels API LLM de 1 à 10 secondes).
• Surcharge Négligeable : L'orchestration des outils, la gestion de la sécurité et le parsing de protocole ajoutent une latence inférieure à 3,5 ms, ce qui est négligeable par rapport à la latence réseau.

C. Résultats des Benchmarks (Tête-à-Tête)

• Terminal-Bench :
  • Rust : 47,5% (38/80 tâches).
  • Python : 42,5% (34/80 tâches).
  • Analyse : L'écart est partiellement dû à des bugs d'API (400) et de transport WebSocket corrigés lors du processus. La parité est considérée comme atteinte compte tenu de la non-déterminisme des LLM.
• SWE-bench Verified :
  • Rust : 70,0% (56/80 tâches).
  • Python : 73,8% (59/80 tâches).
  • Analyse : Le port Python obtient un léger avantage, particulièrement sur les tâches liées à l'écosystème Python (Django), démontrant que la traduction ne nuit pas aux performances réelles.

D. Découvertes de Bugs

Le processus de benchmarking a révélé quatre bugs majeurs invisibles aux tests unitaires :

1. Réponses vides silencieuses sur WebSocket (échec de détection de quota).
2. Identifiant de modèle de mémoire inexistante (erreur 404).
3. Variable non initialisée dans le suivi des coûts.
4. Absence de récupération sur les erreurs HTTP 400 de l'API (résolu par une couche de récupération systématique en Python).

5. Signification et Conclusion

L'article démontre que pour les applications d'agents IA où la latence est dominée par l'API LLM, les avantages expressifs de Python surpassent les bénéfices de performance de Rust.

• Efficacité : Une réduction drastique du code (15,9x) et une complexité accrue facilitent la maintenance et l'extension.
• Paradigme de Migration : La migration ne doit pas être un événement ponctuel mais un processus continu piloté par les benchmarks.
• Divergence Positive : Une fois la parité fonctionnelle atteinte, le port traduit peut évoluer indépendamment pour devenir une plateforme supérieure (sur-ensemble), ajoutant des fonctionnalités impossibles à implémenter aussi rapidement dans le langage d'origine.

En résumé, cette étude valide que l'utilisation de benchmarks comme fonction objectif permet de transformer une migration inter-langage risquée en une opportunité d'innovation, produisant un système plus agile, plus concis et fonctionnellement équivalent, voire supérieur, à l'original.