Les humains ont appris à programmer avec des soulignements rouges, « go to definition » et des erreurs de type qui apparaissent avant même d’avoir fini la fonction. Il paraît logique de donner les mêmes outils aux agents.

Ian Barber a essayé. Le résultat est moins propre qu’un « LSP = meilleur agent ».12

Dans ses expériences sur Python, avec plusieurs modèles locaux et API, ajouter un outil de définition issu d’un LSP ne pousse pas spontanément les modèles à l’utiliser. Ils continuent souvent à faire ce qu’ils connaissent déjà : chercher du texte et lire des morceaux de fichiers.1

Un outil moins cher que l’agent ignore

Sur les tâches testées, un appel de définition coûtait environ 1,3 fois moins de tokens qu’une lecture partielle du fichier. Cela ressemble à une optimisation évidente.1

Sauf que les modèles faisaient régulièrement les deux. Ils demandaient la définition, puis relisaient quand même le fichier. L’économie disparaissait.

Même fournir directement un span contenant la correction ne suffisait généralement pas à empêcher cette seconde lecture. Barber a dû fine-tuner un modèle Qwen 3.6 avec des trajectoires où la lecture était remplacée par l’appel de définition pour modifier durablement ce comportement.1

C’est un rappel utile pour tous les systèmes agentiques : exposer un outil ne signifie pas que le modèle a appris quand lui faire confiance.

Le garde-fou bat le squiggle

L’expérience la plus intéressante concerne le moment où arrive le feedback.

Barber donne à un agent une modification qui passe les tests visibles mais échoue sur un test caché. Sans intervention, le modèle accepte la mauvaise révision 11 fois sur 12. Quand un type checker bloque la soumission en cas d’erreur, il ne l’accepte plus qu’une fois sur 12.1

À l’inverse, injecter les diagnostics en direct pendant la génération, comme des squiggles d’IDE, n’améliore pas le résultat dans ce setup. Demander explicitement au modèle de corriger le feedback pouvait même nuire à son jugement. Les retours groupés en fin de tour ou après une édition se comportaient mieux, avec un avantage de coût pour la fin de tour.1

Le détail change la conception d’un harness. On peut passer beaucoup de temps à rendre les outils visibles au modèle alors que le meilleur endroit pour certains contrôles est peut-être hors de sa boucle de décision : tu proposes ton travail, le système vérifie, et il ne te reparle que si quelque chose casse.

Ne pas transformer une expérience en religion

Barber documente lui-même les limites. Beaucoup de tâches sont synthétiques et faciles. Le test sur le timing des diagnostics utilise un modèle 7B. Les codebases tiennent dans le contexte, et les résultats peuvent changer sur de gros dépôts privés.1

Il cite aussi un contre-exemple important : des travaux où l’exploration de fichiers consomme beaucoup plus de tokens qu’un graphe structuré mais obtient un meilleur résultat. Optimiser le coût d’un appel isolé peut donc dégrader la tâche complète.1

C’est probablement la leçon la plus transférable.

Un agent n’utilise pas un logiciel comme un humain miniature. Lui donner notre IDE, nos boutons et nos habitudes ne garantit rien. Il faut mesurer la trajectoire entière : quel outil il choisit, ce qu’il relit, ce que le garde-fou bloque et si le travail final est réellement meilleur.

Parfois, le meilleur outil pour l’agent est celui qu’on ne lui demande même pas de choisir.