Mon essai non concluant de GLM 5.2

Le jeu affichait un écran noir après les modifications de GLM 5.2, donc rien ne fonctionnait plus. Claude Opus 4.8 a suffi à corriger le tir, ce qui suggère des erreurs ciblées plutôt qu'une réécriture catastrophique.

Sur les 10 tickets lancés, GLM 5.2 a consommé environ 140 000 tokens et près de 5 dollars sans produire un résultat stable. Le ratio coût/fiabilité est clairement défavorable par rapport aux autres modèles testés sur ce projet.

Sur cette codebase dense que les modèles ne connaissent pas nativement, Opus 4.8 s'est montré plus fiable pour maintenir la cohérence du code au fil des tickets. Deepseek v4 Pro a aussi donné de bons résultats, donc le choix dépend aussi du type de tâche.

Un modèle doit inférer les conventions, l'architecture et les dépendances implicites sans contexte préalable, ce qui multiplie les risques d'incohérences entre fichiers. Plus la base de code est spécialisée, comme une décompilation de jeu, moins le modèle peut s'appuyer sur des patterns vus à l'entraînement.

L'auteur prévoit de lui redonner une chance sur des tâches peut-être mieux délimitées. Un échec sur 10 tickets simultanés ne condamne pas forcément un modèle qui pourrait mieux performer sur des tickets isolés ou moins interdépendants.