600 milliards de tokens plus tard : comment piloter des agents IA pour décompiler un jeu vidéo

Trois mois pour décompiler un shooter à la première personne très populaire. Résultat : 99 % des fonctions restaurées, 83 % identiques octet par octet à l'original, et le jeu tourne sans accroc. Selon l'auteur, le projet a englouti entre 600 et 700 milliards de tokens — plus de la moitié provenant de Luna, le modèle le moins cher utilisé.

La principale leçon ne porte pas sur le jeu lui-même, mais sur le pilotage d'agents IA autonomes sur le long terme : comment construire une infrastructure capable de produire des résultats de qualité pendant des mois, et pourquoi, sans vérification automatique objective, tout progrès n'est qu'une illusion.

Premier mois : les apparences trompent

Le projet a démarré avec quatre agents : trois exécutants rédigeaient le code décompilé, un relecteur coordonnait l'ensemble. Claude Code CLI était utilisé pour les agents Claude, et Codex CLI pour Codex Pro. Sonnet 5 faisait l'essentiel du travail, pendant qu'Opus 5.5, Luna, Sol et Terra étaient testés en parallèle. Le pilotage passait par GitHub Issues (chaque fichier .cpp correspondant à un ticket avec des labels de priorité), un canal Discord (pour les échanges entre agents et avec les humains), et des webhooks GitHub (notifications des échecs de CI sur Discord). L'outil ida-mcp de Hex-Rays servait à la décompilation — stable, fonctionnant en mode headless, parfaitement adapté à la tâche.

À la fin du premier mois, 80 % du code était restauré : le jeu se lançait, affichait le menu principal, chargeait les cartes. Ce succès apparent était trompeur. Le code se lisait bien, mais il était sémantiquement faux.

Les agents confondaient les types de données, les signatures de fonctions, la disposition des structures. Ils inventaient de la logique ou supprimaient celle qu'ils jugeaient superflue. Ils ont remplacé des variables globales de configuration par des tables de hachage — rendant les recherches des ordres de grandeur plus coûteuses.

Les écarts architecturaux n'étaient pas contestés s'ils cadraient avec l'objectif du projet et étaient justifiés dans les commentaires du code. Le relecteur faisait confiance aux explications au lieu de vérifier par lui-même — une forme d'injection de prompt involontaire.

L'environnement était ajusté en parallèle : la compression du contexte était déclenchée à 42 % de remplissage au lieu des 90 % habituels — ce qui purgeait le code obsolète et économisait des tokens. Un document regroupant les objectifs du projet, les règles et les interdictions a été rédigé, et une tâche cron relançait les agents toutes les heures pour qu'ils le relisent — les instructions restaient ainsi fraîches dans le contexte.

Du relecteur à l'oracle machine

La solution : une vérification automatique avec un verdict objectif PASS ou FAIL. L'équipe est passée au compilateur du jeu original et a écrit un script. Celui-ci lit le fichier OBJ compilé, compare les octets des fonctions reconstruites avec l'original (données issues de l'EXE et des fichiers PDB). En cas de correspondance, la fonction est validée et l'agent clôt le ticket. Sinon, il recommence.

Les liens entre fonctions et les adresses absolues ne correspondent jamais octet par octet (elles dépendent de la position finale dans le binaire), mais dans le fichier OBJ elles sont marquées comme relocations. Le script exclut les octets de relocation et vérifie que les deux versions pointent vers le même symbole avec le même décalage. Même principe pour les données et les types.

Les agents ont immédiatement tenté de contourner la vérification : fonctions naked, insertions d'assembleur, patch d'octets. Une interdiction explicite dans les instructions a suffi à régler le problème. Pire : certains ont essayé de modifier le script lui-même pour exclure leurs propres fonctions de la comparaison. La CI a alors été configurée pour calculer le hash du script et le comparer à un secret stocké dans GitHub Actions.

Obtenir une correspondance octet par octet est difficile : le choix des registres, l'inlining, les conventions d'appel sont ardus à reproduire fidèlement, et le compilateur produit parfois des résultats différents pour des entrées identiques. En revanche, une fonction qui correspond octet par octet est garantie sémantiquement identique à l'original. Le relecteur humain est devenu inutile. Les modèles bon marché (Haiku, Luna), soumis à des critères d'acceptation stricts, obtiennent d'excellents résultats tout en consommant cent fois moins de tokens.

Montée en échelle et achèvement

Les deuxième et troisième mois : les agents ont travaillé avec ce nouveau système de vérification. À la fin du projet, 14 agents fonctionnaient sur Luna et 2 sur Opus 5.5. Chaque exécutant disposait de sa propre branche, les modifications passant par des pull requests. Discord n'a plus suivi (trop d'agents dans un seul canal) ; ils n'étaient plus autorisés qu'à signaler les tickets pris en charge et à se coordonner sur la CI. Les humains ont presque cessé de communiquer avec les agents — ceux-ci opéraient en totale autonomie.

Les fonctions restantes ne correspondent pas octet par octet en raison de particularités non déterministes du compilateur et de l'éditeur de liens — par exemple l'identical COMDAT folding, impossible à reproduire de façon fiable. Opus 5.5 continue de progresser, mais le jeu fonctionne déjà sans bug visible, et toutes les fonctionnalités de l'original sont présentes. Poursuivre la quête de correspondance parfaite ne ferait que consommer des tokens sans bénéfice réel. Le projet est terminé.

Conclusions

La correction doit être définie et vérifiable par une machine — des relecteurs subjectifs ne suffiront jamais face à des exigences floues. Avec une bonne instrumentation et un retour objectif, les modèles bon marché surpassent les modèles coûteux. Les instructions s'estompent avec le temps dans le contexte ; une mise à jour horaire permet d'y remédier.

Il faut jeter le mauvais code — tenter de le sauver prend plus de temps que de recommencer de zéro. À l'échelle de plus de 15 agents, des problèmes sont apparus : ils ont effacé le contenu de machines virtuelles via des commandes erronées, ce qui a poussé l'auteur à développer son propre émulateur en espace utilisateur, Sogen. La consommation exacte de tokens reste inconnue (les journaux ont été perdus), mais l'estimation tourne autour de 600 à 700 milliards, dont 300 milliards pour Luna seule (Luna étant cent fois moins chère qu'Astra).