Objectif et contexte
Le projet visait à reproduire fidèlement un jeu de tir à la première personne ancien en C++. Les exigences incluaient la lisibilité du code, la capacité de compilation, ainsi que des améliorations de sécurité et de portabilité (Linux, macOS, navigateur). Le but ultime n’était pas seulement de produire un prototype, mais d’évaluer la coordination d’agents autonomes sur plusieurs mois.
Infrastructure et orchestration des agents
Les équipes ont combiné plusieurs modèles de génération de code : Claude Max (20x), Codex Pro, Sonnet 5, Opus 5.5, Luna, Sol et Terra. Les agents Claude s’exécutaient via Claude Code CLI, ceux de Codex via Codex CLI. La gestion des tâches s’appuyait sur GitHub CLI : chaque unité de traduction (.cpp) correspondait à une issue, les libellés servaient à prioriser les travaux. La communication s’est faite sur un canal Discord partagé, où les agents pouvaient publier des messages et recevoir les notifications de CI via un webhook GitHub. Un cron horaire réinjectait un document d’instructions afin de rafraîchir le contexte des modèles, limitant la dérive de focus observée après les cycles de compaction.
Le processus de décompilation s’est appuyé sur
ida-mcpRésultats techniques et limites
Durant le premier mois, quatre agents étaient actifs : trois agents « worker » qui décompilaient et commettaient, et un agent « reviewer » qui coordonnait et signalait les bugs. Le groupe a atteint environ 80 % de couverture du jeu ; le menu principal était fonctionnel et les cartes pouvaient être chargées. Une optimisation majeure a concerné la consommation de tokens : le seuil de compaction du contexte a été abaissé de 90 % à 42 %, ce qui a éliminé les fonctions déjà traitées et a réduit le bruit contextuel.
Malgré ces avancées, la qualité du code généré était insuffisante. Les agents ont souvent attribué des signatures de fonctions, des types ou des structures erronés, ont introduit ou supprimé de la logique, et ont remplacé des accès globaux à des variables de configuration par des tables de hachage coûteuses. L’absence de critères d’acceptation objectifs a limité l’efficacité du reviewer : les justifications inscrites dans les commentaires des commits ont été interprétées comme des preuves de validité, créant une forme de « prompt injection » où le modèle accepte ses propres arguments sans vérification externe.
Le principal enseignement porte sur la nécessité d’un oracle automatisé capable de comparer la sémantique d’une fonction reconstruite à celle de l’original, en renvoyant simplement un signal PASS/FAIL. Un tel mécanisme permettrait aux agents d’identifier rapidement les écarts et de corriger les dérives sans intervention humaine constante.
