Grep bat-il le LSP ? Pourquoi les agents ignorent vos outils

Une étude menée par Pengcheng Xu sur la plateforme AgentConnect révèle que les agents de codage, basés sur des LLM, privilégient souvent des outils de recherche textuelle comme `grep` plutôt que les interfaces sémantiques avancées du Language Server Protocol (LSP). Cette préférence pour la simplicité s'explique par la notion de "LLM-friendliness", où la capacité d'un outil à s'intégrer efficacement dans le flux de travail d'un modèle pèse autant que sa précision technique intrinsèque. Les résultats indiquent que la précision sémantique ne garantit pas une meilleure automatisation si l'interface de l'outil ne fournit pas le contexte nécessaire au modèle pour prendre sa prochaine décision sans surcoût cognitif.

L'expérience a comparé la recherche lexicale via `grep` et la navigation sémantique via LSP sur diverses tâches de localisation et d'édition de code. Sur des tâches simples de localisation, les modèles testés (Opus, Sonnet, Haiku) ont choisi l'outil sémantique dans seulement 0 % à 6 % des cas. Lorsque l'utilisation du LSP leur était imposée, le taux de succès chutait de 100 % à 89 %. En revanche, sur des tâches de complétude de références, consistant à trouver tous les appelants d'une fonction, les modèles se tournaient vers le LSP environ la moitié du temps. Bien que le LSP ait offert une précision de 1,00 contre 0,76 pour `grep` en éliminant les faux positifs, le rappel restait identique dans les deux approches (environ 0,66), suggérant que la limite résidait dans la diligence de l'agent plutôt que dans la qualité de la récupération.

L'analyse démontre que la valeur ajoutée du LSP dépend moins du langage de programmation que de la propreté du codebase. Sur un dépôt TypeScript propre, l'utilisation du LSP n'apportait aucun gain en F1 score et augmentait la consommation de tokens de 16 %. En revanche, sur un dépôt "bruité" contenant de nombreux faux positifs lexicaux, le LSP améliorait le F1 de 0,246 et réduisait l'usage de tokens de 12 %. Le déterminant clé est donc la dégradation de la précision de `grep` due au bruit lexical, et non la présence de typage statique. L'agent semble capable de router intelligemment vers l'outil approprié selon la nature de la tâche et la structure du dépôt.

Au-delà du choix de l'outil, la forme de l'interface de retour (output shape) joue un rôle critique. Les premières versions des outils LSP testés ne renvoyaient que des emplacements (chemin de fichier, ligne, colonne), obligeant l'agent à effectuer des lectures de fichiers supplémentaires pour inspecter le code. En modifiant la réponse pour inclure le texte source directement, similairement au format de sortie de `grep`, l'efficacité a bondi. Le taux de réussite (Pass@1) sur les tâches de renommage est passé de 0,67 à 0,83, et le nombre de lectures de fichiers nécessaires a chuté de 15,2 à 3,2 par épisode. Cela confirme que pour un agent, l'outil n'est pas seulement un backend sémantique, mais une interface qui doit minimiser les étapes intermédiaires.

Les implications pour la conception d'agents sont significatives. L'étude suggère que la structure de la tâche elle-même favorise `grep` pour les modifications textuelles étendues. Contrairement au LSP qui se limite aux références sémantiques, `grep` capture toutes les occurrences textuelles, incluant les commentaires, les chaînes de caractères et la documentation, ce qui est souvent nécessaire pour un renommage complet. Par ailleurs, l'hypothèse d'un biais d'apprentissage lors de l'entraînement des modèles est avancée : les LLM auraient appris des politiques d'action associées à des interfaces familières comme le couple `grep` et lecture de ligne.

Ces observations mettent en lumière le concept de "harness", défini comme l'environnement d'exécution englobant le modèle, incluant les schémas d'outils, leurs formats de retour et les boucles de décision. Une modification de ce harness, même avec le même modèle, peut altérer les capacités effectives de l'agent. Les auteurs conseillent donc d'évaluer tout nouvel outil non pas de manière isolée, mais intégré au sein du système complet, en s'assurant qu'il retourne un contexte suffisant pour la prise de décision et en conservant des solutions de repli lexicales pour les tâches nécessitant une couverture textuelle totale.