Comment Netflix a amélioré l'efficacité de ses agents de codage IA grâce à l'intelligence des EDI JetBrains

JetBrains est une société à responsabilité limitée internationale spécialisée dans le développement de logiciels, qui conçoit des outils destinés aux développeurs et aux chefs de projet. L'entreprise a son siège social à Amsterdam et dispose de bureaux en Chine, en Europe et aux États-Unis. JetBrains propose divers environnements de développement intégrés (EDI), tels que IntelliJ IDEA, PyCharm, WebStorm et CLion. Elle a également créé en 2011 le langage de programmation Kotlin, qui peut s'exécuter dans une machine virtuelle Java (JVM).

Netflix a intégré le moteur d’intelligence de code « headless » de JetBrains – le même que celui qui équipe IntelliJ IDEA – à Claude Code et Codex, puis l’a testé dans divers scénarios. Vous trouverez ci-dessous les détails et les chiffres.


En bref


L’objectif : augmenter le retour sur investissement des agents

JetBrains et Netflix se sont donné pour mission de doter les agents de codage d’une compréhension précise du code, équivalente à celle d’IntelliJ IDEA, dans des environnements sans interface graphique – sans qu’aucune instance d’IntelliJ IDEA ne soit en cours d’exécution.

« Les agents de codage tels que Claude Code sont lents et peu fiables lorsqu’il s’agit de parcourir du code Java/Kotlin, en particulier au-delà des limites des bibliothèques (JAR). Nous avons intégré le moteur de code d’un IDE JetBrains « headless » afin de doter les agents d’une intelligence de code équivalente à celle de l’IDE IntelliJ dans des environnements « headless », sans qu’aucun IDE ne soit en cours d’exécution. Nous avons créé un test de performance avec de véritables tâches de programmation, qui montre qu’avec le moteur de code de l’IDE JetBrains, les agents sont systématiquement plus efficaces : ils utilisent moins de tokens et prennent moins de temps, le gain exact dépendant du modèle. » — Paul Bakker, ingénieur logiciel senior, Netflix

Le problème lié aux fichiers JAR que Netflix tente de résoudre et que Paul décrit ci-dessus : les projets JVM fournissent généralement les bibliothèques uniquement sous forme de fichiers JAR, jamais sous forme de code source. Les agents doivent décompresser les fichiers JAR (en devinant lesquels sont pertinents), éventuellement décompiler les fichiers de classe, puis effectuer des recherches dans cette vue incomplète.

La solution : l’intelligence de l’EDI JetBrains

JetBrains a passé des années à développer le moteur d’intelligence de code qui sous-tend IntelliJ IDEA. Il repose sur un index déterministe de vos fichiers source de projet, y compris toutes les bibliothèques. Cette intelligence est désormais exposée via un LSP et disponible dans les éditeurs compatibles avec VS Code. Netflix a travaillé avec une version « headless » de ce moteur.

Le LSP à lui seul ne suffit pas pour qu’un agent de codage puisse l’utiliser directement : il s’agit simplement d’un serveur utilisant un protocole, sans moyen simple pour un agent de l’appeler et sans gestion intégrée des processus permettant de réutiliser une instance en cours d’exécution entre deux appels. Netflix a comblé cette lacune par ses propres moyens en utilisant le démon et l’interface en ligne de commande (CLI) décrits dans la section suivante.

Architecture en détail : maintenir l’index à jour

La construction d’un index pour un projet prend du temps, tout comme l’ouverture d’un gros projet dans IntelliJ IDEA pour la première fois. Un agent de codage appelle le LSP en plusieurs petites étapes très fines, et une tâche réaliste nécessite plusieurs appels de ce type. Si chacun d’entre eux lançait un nouveau serveur LSP, chaque appel entraînerait un coût de démarrage à froid de plusieurs secondes – même sur un projet dont l’index avait déjà été construit une minute auparavant.

Un processus démon est nécessaire pour éviter la surcharge liée au démarrage à froid du processus serveur LSP lors d’appels répétés. JetBrains travaille à la mise à disposition d’un démon, mais aucun n’était disponible au moment de l’évaluation ; Netflix en a donc développé un pour ses propres besoins :

1. Chaque appel de l’outil était de courte durée et sans état : il se contentait de rediriger vers l’interface en ligne de commande (CLI).

2. Le démon est la composante qui reste active : son gestionnaire de sessions achemine chaque appel, en fonction de la racine du projet, vers le processus serveur correspondant, qui conserve l’index de ce projet en mémoire.

3. Un deuxième appel concernant le même projet ignore complètement l’indexation et passe directement par un serveur « chaud » via stdio.

4. Le démon et l’interface en ligne de commande sont tous deux développés en Java et distribués sous forme d’exécutable GraalVM ; il n’y a donc aucune surcharge liée au démarrage ou à l’exécution de la JVM.

Comment Netflix a mesuré le retour sur investissement de l’intelligence de l’EDI JetBrains

Afin de déterminer si (et dans quelle mesure) l’intelligence de l’IDE JetBrains améliore les performances d’un agent de codage, une suite de tests de performance a été développée. Même modèle, même tâche, même base de code : la seule variable était la capacité de l’agent à faire appel à l’intelligence de l’EDI JetBrains. Les résultats sont présentés sous forme de différence de performances entre les exécutions avec l’intelligence de l’IDE JetBrains et celles sans.

Environnement et approche d’évaluation :


Les tests de performance ont été effectués à plusieurs reprises afin de valider les résultats et d’observer les effets des modifications apportées par les nouvelles versions de LSP.

Résultats

Pour tous les modèles, agents et types de tâches testés, l’intelligence de l’EDI JetBrains a rendu les agents de codage globalement plus efficaces – généralement de 20 à 30 % plus efficaces, et jusqu’à environ 65 % dans le meilleur des cas, en fonction du modèle, de l’agent et de la tâche spécifiques. Ce sont les modèles les plus puissants, nécessitant un effort plus important, qui ont enregistré les gains les plus significatifs. Ces modèles sont plus coûteux, ce qui rend les gains d’efficacité d’autant plus importants, mais ils sont également plus performants dans l’utilisation efficace des index.

Gain d’efficacité par configuration, combinant économies de tokens et de temps. Chaque comparaison exécute deux fois la même tâche, avec le même modèle et la même base de code : une fois avec l’intelligence de l’EDI JetBrains, et une fois sans.


L’efficacité correspond à la moyenne des économies de tokens et de temps pour chaque configuration. La précision est restée stable ou s’est améliorée à chaque exécution. *Tokens uniquement : les appels de recherche par lots de cette configuration ont rendu la comparaison des temps de navigation dans le code non représentative – voir le corps de l’article. Les chiffres constituent un instantané et évolueront avec les nouvelles versions des modèles.

Ces chiffres constituent un instantané, et non un résultat de benchmark fixe. Chaque nouvelle version de modèle modifie la manière dont les agents effectuent leurs recherches, raisonnent et utilisent les outils ; les pourcentages exacts continueront donc à évoluer – c’est pourquoi ce rapport présente des fourchettes plutôt que des résultats par modèle. Ce qui est resté constant d’un test à l’autre chez Netflix, c’est la tendance générale : chaque modèle et chaque agent testé a gagné en efficacité, les gains les plus importants ont été obtenus par le modèle le plus performant avec un niveau d’effort élevé, et l’ampleur du gain variait sensiblement d’un modèle à l’autre.

Tâches de navigation dans le code : une efficacité accrue à tous les niveaux, une précision maintenue ou améliorée

Tous les modèles et tous les niveaux d’effort testés ont utilisé moins de tokens grâce à l’intelligence de l’IDE JetBrains – sans aucune exception –, avec des économies allant d’environ 15 % à 60 %. L’ampleur du gain dépendait principalement du modèle : le modèle le plus performant a enregistré de loin les plus grandes améliorations, tandis que les configurations plus légères se situaient dans la partie inférieure des deux fourchettes. La précision est restée stable dans la plupart des essais et s’est améliorée dans deux d’entre eux – elle n’a jamais baissé.

Pour les tâches de navigation dans le code en particulier, une combinaison outil/modèle regroupe déjà plusieurs appels de recherche en une seule commande ; ainsi, avec ou sans l’intelligence de l’IDE JetBrains, un seul appel à l’outil est effectué à ce stade. L’appel à l’intelligence de l’EDI JetBrains est légèrement plus lent pour cet appel unique que la commande de recherche groupée – ce qui explique l’absence manifeste de gain de temps pour cette combinaison, qui ne reflète pas fidèlement l’utilisation en conditions réelles. C’est pourquoi la suite de tâches de bout en bout, plus large, constitue un indicateur plus fiable en termes de temps : l’intelligence de l’IDE JetBrains s’est avérée plus rapide pour tous les modèles et agents testés.

Tâches de bout en bout : une efficacité systématiquement supérieure, sans incidence sur la précision

Lors de l’exécution étendue de bout en bout, la précision est restée stable pour tous les modèles et agents testés ; l’avantage réside donc entièrement dans l’efficacité, et non dans la simple réalisation de la tâche. Chaque combinaison de modèle et d’agent s’est avérée environ 10 à 30 % plus efficace avec l’intelligence de l’IDE JetBrains, si l’on considère le temps nécessaire à l’exécution et la consommation de jetons. Cela s’explique en grande partie par le fait que moins d’appels d’outils sont nécessaires pour parvenir aux mêmes conclusions.

Autres alternatives évaluées

Avant d’opter pour l’approche décrite, Netflix a écarté deux autres solutions. La première rejetée était une interface CLI interne développée en interne qui se connectait à une instance d’IntelliJ IDEA en cours d’exécution pour accéder à un index de projet. Le processus est similaire à celui décrit dans cet article, mais il nécessite qu’un EDI soit en cours d’exécution. Cette approche ne convenait pas aux agents « headless » pour des environnements tels qu’Otto, Bitbot, les outils de refactorisation distribués, l’intégration continue (CI), etc.

Deuxièmement, un LSP Eclipse existant, utilisé pour Java dans VS Code, a été envisagé. Mais pour le système de build de Netflix (basé sur Gradle), cela ne fonctionnait tout simplement pas.

Prochaines étapes

Quelle direction Netflix va-t-elle prendre ?

À l’issue du test, Netflix a conclu que « les tests de performance montrent qu’il y a un avantage à disposer d’une couche d’intelligence déterministe aux côtés de votre agent ». Bien sûr, cela ne réduit pas chaque tâche des agents de codage d’un pourcentage fixe. Mais pour ce problème spécifique – la résolution de la structure réelle au-delà des limites des fichiers JAR –, l’avantage est considérable, vaut pour tous les modèles et n’entraîne aucune perte d’exactitude.

Netflix prévoit d’appliquer la même méthodologie de benchmark à Python, TypeScript/JavaScript et Go. Les agents de codage pour ces langages rencontrent des problèmes similaires. Mais bien sûr, la manière dont les bibliothèques sont téléchargées dans un projet varie selon le langage ; les mécanismes des problèmes et les solutions possibles diffèrent donc. JetBrains prévoit de poursuivre cette collaboration et de soutenir davantage cette évaluation.

Le point de vue de JetBrains : le LSP n’est qu’une étape, pas une fin en soi

L’intelligence de l’EDI JetBrains pour Java a été testée par Netflix et est désormais fournie dans le cadre de l’extension « Java & Kotlin by IntelliJ IDEA ». JetBrains poursuit également ses expérimentations avec l’approche LSP+CLI et communiquera les résultats dès qu’ils seront prêts.

La primitive de base du LSP est une position dans un document texte. La spécification définit une position comme « l’espace entre deux caractères, à l’instar d’un curseur d’insertion dans un éditeur ». Il s’agit là d’une primitive naturelle pour un utilisateur travaillant au clavier. Mais les agents ne raisonnent pas vraiment en termes d’emplacement du curseur. Ils posent des questions sur le programme, telles que « Pourquoi cet appel à l’intérieur de createUser() n’est-il pas résolu ? » ou « Quels tests couvrent cette méthode ? », etc. Il s’agit de comprendre les relations entre les différentes parties du code plutôt que de se concentrer sur les positions du curseur. De plus, une position dans le texte est une identité fragile : l’insertion d’un seul caractère avant une position donnée entraîne le déplacement de cette position.

Ce dont un agent a besoin, ce n’est pas d’un curseur plus précis, mais d’une couche qui fournisse des réponses formulées de la même manière que les tâches elles-mêmes – c’est-à-dire en termes de symboles, de diagnostics, de relations de test, de comportement d’exécution – et qui renvoie suffisamment de contexte pour raisonner sur la réponse, et pas seulement des emplacements dans un document texte.

« C’est ce que j’entends par “moteur de code” : non pas un protocole de plus permettant à un agent d’imiter l’interaction avec un éditeur, mais un ensemble d’opérations précises portant sur la structure et l’exécution du programme – un ensemble qui renvoie suffisamment de contexte pour permettre de véritablement raisonner sur le résultat. Le LSP est utile, mais il ne devrait pas définir l’abstraction finale destinée à l’agent. Si vous concevez les outils destinés aux agents comme si ceux-ci étaient de minuscules êtres humains devant un éditeur, vous les forcez à s’exprimer en coordonnées de curseur. Les agents ont besoin d’un moteur de code, pas d’un éditeur virtuel. » — Aleksey Stukalov, responsable de la division EDI, JetBrains

Les chiffres de Netflix prouvent que l’intelligence de code vaut la peine d’être financée. Déterminer quelle forme prendra cette intelligence est le défi qui nous attend.

Découvrez le système d'IA agentique de JetBrains