Nous avons fourni aux agents des outils de recherche natifs aux EDI : Ils ont ainsi gagné en rapidité et en rentabilité

Par JetBrains

Nous avons fourni aux agents des outils de recherche natifs aux EDI : Ils ont ainsi gagné en rapidité et en rentabilité, par JetBrains

Nous avons exécuté les mêmes tâches de codage avec et sans outils préintégrés, sur plusieurs modèles et langages. Voici ce qui a changé.


Pourquoi nous avons développé cela

Lorsque les agents codent, ils ont par défaut recours aux outils shell. grep et find fonctionnent, mais ils ne tiennent pas compte de la structure du projet, des limites des symboles et de la sémantique du langage. L'agent gaspille des jetons en passant au crible des résultats bruyants et en effectuant des appels de suivi pour affiner les résultats.

Nous avons donc essayé une solution évidente : et si l'agent pouvait utiliser la recherche propre à l'EDI à la place ?

Nous avons développé une compétence préintégrée qui associe une invite de recherche à un outil MCP unifié. Un outil, quatre modes : recherche de fichiers, recherche de texte, expressions régulières et recherche de symboles. Un routeur universel achemine les appels vers le backend approprié.

Outils MCP : Fonctions que l'agent appelle via un serveur MCP pendant l'exécution d'une tâche. Les outils natifs de l'EDI peuvent exploiter des index, des AST et des modèles de projet que les outils shell ne peuvent pas voir.

Compétences : Comportements d'agent packagés : une invite associée à une logique d'orchestration. Une compétence peut fonctionner de manière autonome, utiliser des outils ou être livrée avec les outils dont elle a besoin.

Rien n'est livré par défaut tant que l'évaluation n'en a pas donné l'autorisation. Nous avons testé quatre configurations différentes de cet ensemble d'outils avant d'en choisir une.

Méthodologie

Le pipeline d'évaluation lance un serveur MCP parallèlement à l'EDI afin que l'agent ait accès aux outils et compétences configurés. Nous exécutons des tâches de codage identiques avec et sans outils, puis nous comparons les résultats à l'aide d'une analyse delta par paires.

Nous suivons quatre indicateurs : la qualité, la latence, le coût et la discipline budgétaire. La qualité consiste à vérifier si tous les tests ont été réussis. La latence suit le temps médian et le temps P95 des tâches. Le coût convertit la consommation de jetons en dollars. La discipline budgétaire suit la fréquence à laquelle une tâche individuelle dépasse le plafond budgétaire de 0,50 USD.

Nous ne signalons les deltas d'amélioration que lorsqu'ils dépassent notre seuil de signification : p < 0,05, test apparié avec des intervalles de confiance à 95 %. Les métriques ne présentant pas de changement significatif sont soit omises des graphiques, soit signalées explicitement. Nous avons testé quatre variantes de configuration, sélectionné celle offrant le meilleur compromis entre latence et coût, puis l'avons réexécutée sur différents modèles et langages pour vérifier la validité des résultats.


Résultats

La configuration sélectionnée comprenait une compétence de recherche préintégrée, ainsi qu'un outil natif de l'EDI unifié et un routeur universel. Par rapport à la référence sans outil, elle a réduit la latence et le coût sans entraîner de changement statistiquement significatif en termes de qualité.


Explorateur de configuration

Nous avons testé quatre configurations d'outils avant de choisir la configuration finale. Une latence plus faible et un coût total plus bas sont préférables, c'est pourquoi le coin inférieur gauche du graphique est la cible.


Validation inter-modèles

Nous avons réexécuté l'expérience avec GPT 5.4 sur des bases de code Java et Kotlin. La tendance se confirme : la latence et le coût diminuent tous deux. C'est Kotlin qui a enregistré la plus forte amélioration en termes de coût, avec une baisse du coût total de 13,48 %.


Comment les modèles adoptent les outils

Codex envoie 91 % de ses requêtes de recherche via le nouvel outil natif de l'EDI. Claude est un cas à part : Opus l'utilise pour environ la moitié de ses recherches, et Haiku seulement 28 %, préférant plutôt grep et find.

Cela est logique. Claude dispose déjà d’une puissante fonctionnalité de recherche de code intégrée, il s’appuie donc sur ce qu’il connaît. Ce n’est pas le cas de Codex, qui utilise donc le meilleur outil lorsqu’il est disponible. Conclusion : les outils préintégrés comblent les lacunes. Lorsque le modèle dispose déjà d’une bonne fonctionnalité de recherche, l’apport est moindre. Lorsque la recherche est faible, cela fait une réelle différence.


Prochaines étapes

Le pipeline d’évaluation fonctionne. Nous l’utilisons désormais.

Nous allons ensuite mener la même expérience sur des modèles plus petits. Nous pensons qu’ils en tireront encore plus de bénéfices, car ils disposent de moins de capacités de recherche intégrées sur lesquelles s’appuyer.

Les résultats actuels sont les plus probants sur Java et Kotlin. Nous étendons nos tests à Python, .NET et TypeScript avec des échantillons plus importants.

Parallèlement, la configuration gagnante est en cours de préparation pour le serveur MCP intégré à IntelliJ IDEA, afin que les sessions d'agent puissent utiliser les outils natifs de l'EDI lorsque le serveur est activé.

La prochaine étape consiste à activer cette fonctionnalité par défaut dans les prochaines mises à jour du plugin AI Assistant.

Vous souhaitez l'essayer avant son déploiement par défaut ?

1. Définissez ces clés de registre sur true : llm.chat.agent.codex.mcp.idea, llm.chat.agent.skills.settings.enabled et llm.agents.contrib.bundled.skills.sync.enabled.

2. Dans l'Assistant IA, choisissez Codex pour obtenir les meilleurs résultats.

3. Demandez à l'agent de rechercher quelque chose dans le projet en cours.

Mesurez d'abord, déployez ensuite, continuez à mesurer après. C'est toute l'approche.

Voir les solutions d'IA de JetBrains