Et si un modèle IA gratuit pouvait écrire du code de jeu, lancer les tests, et passer à la tâche suivante — tout seul ?
C’est exactement ce que j’ai testé cette semaine. Trois expériences, trois échecs progressifs, et finalement : une tâche complétée de bout en bout par un agent IA autonome, sans intervention humaine, pour zéro euro.
Le setup
Je travaille sur un projet DragonRuby : reproduire le bonus stage de Sonic 1 (Megadrive) avec des lookup tables, en résolution GameBoy (160×144). Le code est en Ruby (mRuby), les tests avec dr_spec, le workflow en git flow.
Pour l’automatisation, j’utilise :
- Ralph TUI : un orchestrateur de boucles d’agents IA. Il lit une liste de tâches (PRD), lance l’agent, détecte la complétion, passe à la tâche suivante.
- OpenCode : un CLI d’agent IA (comme Claude Code, mais multi-modèle).
- MiniMax M2.5 free : un modèle IA gratuit qui score 80.2% sur SWE-bench — quasi au niveau de Claude Opus (80.8%).
L’expérience
J’ai donné à Ralph une tâche simple : créer un module de lookup table sin/cos en fixed-point Q8 (entiers, pas de float — comme sur Megadrive). Avec des specs, des tests, et un commit.
Tentative 1 : l’échec silencieux
Ralph tourne 5 itérations. M2.5 écrit le code. C’est propre. Mais :
- Il n’a jamais lancé les tests (DragonRuby introuvable — le binaire est hors du projet)
- Il n’a jamais signalé la complétion (Ralph attend un signal spécifique :
<promise>COMPLETE</promise>) - Résultat : 7 minutes pour rien. 0 tâche complétée.
Tentative 2 : le debug en boucle
Je corrige le chemin DragonRuby dans la doc. Ralph relance. M2.5 trouve le binaire, lance les tests… et découvre que le runner de tests est cassé. Il passe 10 minutes à debugger dragon_specs.rb (un fichier copié d’un autre projet avec des requires en dur vers des fichiers qui n’existent pas). Je stoppe.
Tentative 3 : la complétion
Je corrige tout : le runner de tests, les syntaxes incompatibles mRuby, les matchers inexistants. Je réécris le PRD avec des instructions ultra-précises : étapes numérotées, chemin du binaire, matchers exacts, pièges mRuby listés.
Résultat :
| Exp 001 | Exp 002 | Exp 003 | |
|---|---|---|---|
| Tâches complétées | 0/3 | 0/3 | 1/1 |
| Durée | 7m28 | 10min+ (stoppé) | 2m23 |
| Tests DR | Jamais lancés | Crash | 25 tests, exit 0 |
| Signal COMPLETE | Non | Non | Oui |
| Coût | 0 € | 0 € | 0 € |
Ce que j’ai appris
1. Un modèle gratuit peut coder — mais il faut lui mâcher le travail
M2.5 a produit du code Q8 correct dès la première tentative. Mais il ne savait pas :
- Où trouver le binaire de test
- Que mRuby n’a pas les mêmes syntaxes que Ruby standard
- Quels matchers existent vraiment dans le framework de test
- Comment signaler à Ralph qu’il a fini
Chacun de ces points a nécessité une correction dans la doc du projet.
2. Le vrai travail c’est le template, pas le code
Sur 3 expériences, j’ai passé 80% du temps à écrire de la doc et 20% à regarder l’IA coder. C’est contre-intuitif : on pense que l’IA va nous faire gagner du temps, mais le temps se déplace vers la préparation.
La bonne nouvelle : ce travail de template est cumulatif. Chaque erreur corrigée dans la doc évite des dizaines d’échecs futurs.
3. Le coût est imbattable
Claude Opus coûte ~0.50–1.00 € par run (5/25 € par million de tokens). M2.5 free = 0 €. Sur des dizaines d’itérations Ralph, la différence est massive.
Et la qualité du code ? Quasi identique. Les deux produisent du Q8 correct, des specs propres, du Sandi Metz conforme.
La suite
J’ai 7 issues découpées en TDD sur le projet. L’objectif : faire tourner Ralph sur les 3 premières de bout en bout, sans intervention. Puis comparer les performances de différents modèles gratuits sur les mêmes tâches.
Suivre cette série
C’est le premier article d’une série sur l’automatisation du dev de jeux avec des agents IA. Au programme :
- Faire tourner Ralph sur 3 tâches enchaînées avec dépendances
- Comparer les performances de différents modèles gratuits sur les mêmes tâches
- Construire un damier rotatif style Megadrive — entièrement codé par un agent
Si ça vous parle, vous pouvez me retrouver sur GitHub ou suivre ce blog — chaque étape est documentée en détail, code inclus.