2026-06-01 Rétrospective
Ce que j'ai fait aujourd'hui
Aujourd'hui, j'ai exécuté directement le projet Godot pour vérifier le résultat de la génération de la carte, et, dans ce processus, j'ai de nouveau testé à quel point les outils de codage IA suivaient réellement les tâches de développement de jeux.
J'ai également personnalisé le MCP de recherche Web dans mon dépôt privé. Au lieu d'utiliser tel quel le web-search-mcp de base, j'ai essayé de l'adapter à mon flux de recherche et à la sortie que je souhaite. En traitant des informations qui évoluent constamment comme le design, Godot ou la documentation récente, j'ai senti que l'outil de recherche était presque indispensable.
Outils testés
J'ai testé Qwen Code, Codex et OpenCode.
Pour aller droit au but, aucun n'était aussi stable que je l'espérais. Qwen Code produisait des réponses répétitives trop souvent. Le même plan était élaboré, le même fichier recherché, le même chemin échoué était de nouveau suivi, créant un cycle récurrent. Sans réglage et tuning selon la documentation, il semble difficile d'améliorer ce problème quel que soit le modèle utilisé.
Codex et OpenCode étaient meilleurs que Qwen Code en ce qui concerne l'appel d'outils, mais ils ne comprenaient pas profondément le contexte du travail sur Godot ou interprétaient mal les images. Les réponses se coupaient parfois, le modèle élaborait un plan sans le finaliser correctement, et il invoquait un sous‑agent qui, sous prétexte de recherche, parcourait le système de fichiers de façon étrange.
Lorsque ce n'était pas Qwen Code, l'intégration du MCP web-search ne fonctionnait pas bien, ce qui était décourageant. À l'inverse, avec Qwen Code, même en utilisant le MCP, les problèmes de répétition et d'interprétation d'état persistaient.
Expérimentation de modèles
D'autres modèles ont tendance à proposer des motifs de code d'anciennes versions de Godot plutôt que de la version la plus récente. En cherchant un modèle dédié à Godot, j'ai essayé le modèle bekoozkan/godot-gemma-4-e4b-it-GGUF de Hugging Face.
J'espérais qu'il comprendrait un peu mieux Godot, mais les limites étaient importantes. Le modèle possède trop peu de paramètres et ne saisit pas bien les longs contextes.
En particulier, pour les tâches où la vérification d'images est cruciale, la frustration était grande. Il faut juger si la carte apparaît anormale, où elle semble étrange, en regardant l'écran réel, mais les modèles n'ont pas pu interpréter les images de façon fiable. Dans le développement de jeux, il ne suffit pas que le code soit correct ; il faut aussi que l'affichage soit naturel, et c'est là que les outils IA ont beaucoup vacillé.
Problèmes rencontrés dans le travail avec Godot
Godot était un domaine que les modèles connaissaient moins bien que prévu. La syntaxe récente, la structure des scènes, le comportement de l'éditeur, les chemins des ressources et la vérification du résultat d'exécution sont tous interconnectés, mais plusieurs modèles se contentaient de répondre à partir de fragments de code en s'appuyant sur des connaissances dépassées.
Le travail réel que j'ai effectué aujourd'hui s'est limité à lancer Godot et à vérifier le problème d'affichage de la carte. Mais autour de cela, j'ai dû constamment ajuster les paramètres des outils, connecter le MCP, changer de modèle, gérer les problèmes de sandbox, et résoudre les difficultés d'interprétation d'images. En fait, le temps passé à manipuler les outils a été plus long que le temps passé sur le jeu lui‑même.
Sentiments restants
Honnêtement, j'ai l'impression que ce domaine ne me correspond pas vraiment.
Je pensais que bien assembler les outils IA rendrait le développement plus facile, mais en pratique, il faut constamment vérifier que l'outil ne perd pas son état, ne répète pas, ne cherche pas le mauvais fichier, ne rate pas les images, et ne propose que du code obsolète. Ce que je veux créer, c'est un jeu, et je passais mon temps à déboguer les limites des outils.
Cela dit, j'ai tiré quelques leçons. Le MCP de recherche Web est indispensable, Qwen Code doit être fortement tuné selon la documentation, et le travail sur Godot doit toujours être accompagné d'une validation visuelle réelle. Plutôt que de confier toute la planification et l'exécution à un LLM, il est plus réaliste de laisser les personnes ou les scripts gérer la boucle de validation, le LLM ne servant qu'à la rédaction de brouillons et à l'aide à la décision.
À partir de demain, je pense devoir me lancer dans le fine‑tuning. Se contenter d'utiliser un modèle générique ou un modèle Godot public ne suffit pas à suivre la version de Godot, le mode de travail et le flux de validation visuelle que je souhaite. Il faut rassembler les exemples et les cas d'échec pertinents pour créer un jeu de données adapté à ma façon de travailler.
Critères à laisser pour la suite
- Le travail sur Godot n'est pas considéré comme terminé sans vérification de l'affichage en cours d'exécution.
- Les tâches nécessitant un jugement basé sur des images ne se fient pas uniquement aux réponses du modèle.
- Dès demain, je rassemblerai les modèles de travail et les cas d'échec de Godot pour préparer un fine‑tuning.
- Qwen Code sera utilisé uniquement après avoir configuré les paramètres de prévention des répétitions et le MCP.
- Codex et OpenCode sont considérés comme faibles sur le contexte Godot et l'interprétation d'images.
- Si le modèle ne parvient pas à établir un plan et ne fait que répéter les appels d'outils, il faut arrêter immédiatement.
- La recherche Web reste nécessaire, mais la décision de transformer les résultats en code doit être vérifiée séparément.