Ce qui se casse quand on exécute des agents de codage sur de petits modèles locaux

Après des semaines à exécuter de vraies tâches de codage multi-fichiers via de petits modèles locaux (moins de 7B) et de petits modèles cloud sur des offres gratuites, un utilisateur de Reddit a documenté des points de défaillance récurrents, au-delà du bruit habituel des benchmarks. Voici ce qui coince vraiment.

Les délimiteurs Markdown sont la panne la plus fréquente

Même avec "afficher uniquement du code brut, sans formatage markdown" dans le prompt système, la plupart des modèles encapsulent leurs réponses dans des triples backticks. Qwen3.5:9b et Gemma4:e4b suivent le mieux les instructions mais dérapent encore parfois. La solution n'est pas un meilleur prompt — c'est de supprimer les délimiteurs en post-traitement par défaut.

Les sorties structurées ne sont pas fiables en dessous de 7B

Lorsque les agents ont besoin de JSON pour des listes de tâches ou des types d'action, les petits modèles échouent bien plus souvent que ne le suggèrent les benchmarks. Les benchmarks testent du JSON valide ; l'usage réel ajoute des instructions complexes en plusieurs étapes avec des cas limites. Gemma4:e4b est le plus fiable parmi les modèles locaux ; Qwen3.5:9B suit de près. Codellama galère. Dans le cloud, Llama 3.3 70B sur Groq est très solide. Solution pratique : valider le JSON, réessayer une fois avec une instruction explicite, puis utiliser un analyseur permissif qui extrait le JSON du texte.

Les modèles modifient le mauvais fichier

Donnez à un petit modèle la tâche de renommer validateToken en verifyToken avec un plan de projet contenant des noms similaires, et il peut renommer validateUser ou modifier un fichier complètement différent. Le modèle traite le plan de projet comme des suggestions, pas des contraintes. Correction au niveau de l'orchestration : valider que les chemins de fichiers existent et que les noms de fonctions sont dans les fichiers déclarés. Renvoyer des erreurs en cas de divergence — les petits modèles mentent avec assurance.

Classification question vs action

Demander « combien de lignes fait utils.js » devrait être une opération en lecture seule. Mais si l'exécuteur n'a qu'un seul mode d'édition, il éditera le fichier pour y mettre la réponse. La solution : le planificateur doit classer les requêtes en types d'action avant exécution. Les requêtes en lecture seule sont dirigées vers un chemin de code séparé qui ne touche jamais au disque.

Ce qui fonctionne mieux que prévu

• Respect du budget de tokens dans le code : Compter les tokens avant chaque appel ; les petits modèles n'ont pas conscience des limites de contexte et ne seront pas concis si on leur fait confiance.
• Isolation par fichier : Envoyer un fichier à la fois est nettement plus fiable que deux — les modèles mélangent les corrections.
• Mémoire synthétique : Stocker un résumé d'une phrase de ce que le modèle a fait, pas la liste complète des tâches. Fonctionne pour les annulations et les requêtes additives.

Encore à déterminer

Si un modèle local de moins de 7B est viable pour un rôle d'agent — l'auteur n'en a pas encore trouvé un qui n'échoue pas assez souvent sur les sorties structurées. Banc de test open source sur github.com/razvannec pour les contributions.