La moitié de mes sessions IA commencent mal — c'est normal

Sur 128 sessions de coding agent analysées automatiquement (scoring post-session par le modèle), 68 ont été marquées avec une friction “wrong_approach”. 53%. La moitié du temps, l’agent part dans la mauvaise direction au premier essai.

Ce que les données montrent

Le scoring post-session de Claude Code classe les frictions en catégories. Précision utile : même pendant ma période OpenCode/Kilo Code, Claude Code a continué à tourner en parallèle — c’est de cet historique-là que viennent les données. Sur plusieurs mois d’usage quotidien :

wrong_approach      68 occurrences (53%)
buggy_code          33 occurrences (26%)
excessive_changes    8 occurrences  (6%)
misunderstood_req    7 occurrences  (5%)

“wrong_approach” domine largement. L’agent comprend la demande mais choisit une stratégie d’implémentation inadaptée — un pattern qui ne colle pas au contexte du projet, une abstraction inutile, un refactoring trop ambitieux pour le scope.

Pourquoi c’est normal

L’agent n’a pas la mémoire du projet entre les sessions. Il découvre le contexte à chaque fois. Son premier instinct est basé sur les patterns les plus courants dans ses données d’entraînement — pas sur les conventions spécifiques de ta codebase.

C’est exactement ce qui se passe quand un développeur compétent rejoint un nouveau projet : les premiers jours, il propose des solutions “standard” qui ne collent pas aux conventions locales. La différence, c’est que l’agent fait ça à chaque session.

Ce que ça change dans le workflow

Savoir que le premier essai a 50% de chances d’être un wrong_approach change la façon dont on structure les sessions :

Briefer les contraintes, pas juste la tâche. “Ne modifie pas l’interface publique”, “Utilise les helpers existants dans AbstractServiceTest” — les contraintes négatives réduisent le wrong_approach plus efficacement que des instructions détaillées.

Couper tôt. Si après 2-3 échanges l’approche ne converge pas, ouvrir une nouvelle session avec un prompt reformulé est plus efficace que de corriger en cours de route. Le context rot d’une session qui a dévié est difficile à rattraper.

Ne pas interpréter le wrong_approach comme un échec. 62 des 128 sessions scorées sont “fully achieved” malgré les frictions. L’agent corrige le tir — à condition qu’on le guide.

Le vrai signal

Le chiffre qui compte n’est pas le taux de wrong_approach — c’est le taux de fully_achieved : 48%. Presque la moitié des sessions atteignent complètement leur objectif. 35% l’atteignent partiellement. Seules 2 sessions sur 128 sont un échec complet.

L’agent se trompe souvent au départ mais finit généralement par trouver. Le workflow efficace n’est pas d’éliminer l’erreur initiale — c’est de la détecter vite et de pivoter.

C’est aussi le chiffre que je montre en premier à quelqu’un qui débute sur les agents — pour qu’il n’interprète pas son premier wrong_approach comme un signe qu’il s’y prend mal.

→ Guide : Principes du workflow agentique → Guide : Prompt engineering pour les agents de coding