[Перевод] Как Netflix повысила эффективность ИИ-агентов для программирования с помощью JetBrains IDE

JetBrains и Netflix поставили перед собой задачу обеспечить ИИ-агентам точное понимание кода на уровне IntelliJ IDEA в средах без графического интерфейса без необходимости запускать саму IDE.

ИИ-агенты для программирования, такие как Claude Code, медленно и ненадёжно ориентируются в Java/Kotlin-коде, особенно когда нужно переходить через границы библиотек (JAR). Мы интегрировали движок анализа кода JetBrains IDE, работающий без графического интерфейса, чтобы предоставить агентам возможности интеллектуального анализа кода уровня IntelliJ IDEA без запуска IDE.

Мы создали бенчмарк на основе реальных задач программирования. Он показал, что благодаря движку JetBrains IDE агенты стабильно работают эффективнее — расходуют меньше токенов и времени, хотя конкретный прирост зависит от модели.

— Пол Баккер (Paul Bakker), ведущий инженер-программист Netflix

Проблема JAR-файлов, о которой говорит Пол, заключается в следующем: в проектах на JVM библиотеки обычно распространяются исключительно в виде JAR-файлов, без исходного кода. Поэтому агентам приходится распаковывать JAR-архивы, пытаясь угадать, какие из них нужны, при необходимости декомпилировать файлы классов, а затем искать информацию с помощью grep в полученном неполном представлении кода.

Решение: интеллектуальный анализ кода JetBrains IDE

JetBrains много лет разрабатывала движок интеллектуального анализа кода, лежащий в основе IntelliJ IDEA. Он использует детерминированный индекс исходных файлов проекта, включая все библиотеки.

Теперь эти возможности доступны через LSP (Language Server Protocol) и могут использоваться в редакторах, совместимых с VS Code. Netflix работала с версией этого движка, способной функционировать без графического интерфейса.

Однако одного LSP недостаточно, чтобы ИИ-агент мог напрямую с ним взаимодействовать. LSP — это всего лишь сервер, реализующий определённый протокол. Он не предоставляет агенту удобного способа обращаться к нему и не содержит встроенного механизма управления процессами, позволяющего повторно использовать уже запущенный экземпляр сервера.

Netflix самостоятельно устранила этот недостаток, разработав фоновый сервис и CLI, о которых речь пойдёт далее.

Архитектура: как сохранить индекс в памяти

Построение индекса проекта требует времени — точно так же, как при первом открытии большого проекта в IntelliJ IDEA.

ИИ-агент обращается к LSP многократно, выполняя небольшие специализированные операции. Для решения реальной задачи обычно требуется несколько таких обращений. Если при каждом запросе запускать новый LSP-сервер, придётся снова и снова платить за «холодный старт», занимающий несколько секунд. Причём даже в том случае, если индекс этого проекта был построен всего минуту назад.

Чтобы исключить накладные расходы на повторный запуск LSP-сервера, необходим постоянно работающий фоновый процесс — daemon. JetBrains разрабатывает такой сервис, однако на момент проведения испытаний он ещё не был доступен. Поэтому Netflix создала собственное решение.

Архитектура работает следующим образом:

1. Каждый вызов инструмента кратковременен и не сохраняет состояние — он просто запускает CLI.

2. Фоновый сервис остаётся работающим. Его менеджер сессий определяет корневой каталог проекта и направляет запрос соответствующему серверному процессу, который хранит индекс проекта в оперативной памяти.

3. Повторный запрос к тому же проекту полностью пропускает этап индексации и сразу обращается к уже запущенному серверу через стандартные потоки ввода-вывода (stdio).

4. И фоновый сервис, и CLI написаны на Java и распространяются в виде исполняемого файла, собранного с помощью GraalVM. Это позволяет избежать накладных расходов, связанных с запуском и работой JVM.

Как Netflix измеряла окупаемость интеллектуального анализа кода JetBrains IDE

Чтобы выяснить, действительно ли технологии JetBrains IDE повышают производительность ИИ-агентов и насколько велик этот эффект, была разработана специальная система бенчмарков. Условия оставались одинаковыми: одна и та же модель, одна задача и одна кодовая база. Единственная переменная — наличие или отсутствие у агента доступа к интеллектуальному анализу кода JetBrains IDE. Результаты оценивались как разница в производительности между запусками с этой технологией и без неё.

Среда и методика тестирования

Наборы данных

Две реальные кодовые базы:

• Внутренний сервис среднего размера, использующий Spring Boot 4 и Gradle.

• Собственный открытый проект Netflix — DGS Framework, фреймворк для GraphQL, написанный на Kotlin и Java.

Задачи

Два типа:

• Небольшие специализированные задачи, в которых агент должен разобраться в отдельных аспектах кодовой базы. Например: «Где в проекте используется этот интерфейс?», «Какие реализации существуют у этого интерфейса?», «Как устроен этот класс?».

• Полноценные задачи полного цикла (end-to-end): реализация новой функциональности, рефакторинг класса или удаление кода.

Модели

• Claude Code с Opus 5 (средний и высокий уровень вычислительных усилий).

• Claude Code с Sonnet 5 (средний и высокий уровень вычислительных усилий).

• Codex с GPT-5.6 Sol (средний и высокий уровень вычислительных усилий).

Оценка результатов

Главными показателями эксперимента были расход токенов и время выполнения задачи. Для проверки корректности результатов использовалась большая языковая модель в роли оценщика (LLM-as-a-judge). В задачах полного цикла она сравнивала результат с эталонным набором изменений, а в задачах навигации по коду применялась детерминированная метрика оценки.

Обработка выбросов

Если при выполнении задачи происходил сбой, достигался лимит бюджета или агент зацикливался на неэффективных действиях в одном из вариантов эксперимента, соответствующая задача исключалась из обоих вариантов.

Таким образом, единичный неудачный запуск не мог исказить результаты сравнения.

Бенчмарки запускались многократно, чтобы подтвердить результаты и оценить влияние изменений в новых версиях LSP.

Результаты

Во всех протестированных сочетаниях моделей, агентов и типов задач технологии интеллектуального анализа кода JetBrains IDE в целом повышали эффективность ИИ-агентов.

Обычно прирост составлял 20–30%, а в лучшем случае достигал примерно 65% — в зависимости от конкретной модели, агента и задачи.

Наибольшую выгоду получали наиболее мощные модели при высоком уровне вычислительных усилий.

Такие модели обходятся дороже, поэтому повышение эффективности особенно важно. Кроме того, они лучше умеют использовать индексы кода.

Прирост эффективности в разных конфигурациях

Показатель объединяет экономию токенов и времени. Для каждого сравнения одна и та же задача выполнялась одной и той же моделью на одной кодовой базе дважды — с доступом к технологиям JetBrains IDE и без него.

Эффективность рассчитывалась как среднее значение экономии токенов и времени для каждой конфигурации. Корректность результатов во всех запусках либо оставалась на прежнем уровне, либо улучшалась.

Для значения ~17% учитывалась только экономия токенов. Пакетная обработка поисковых запросов в этой конфигурации делала сравнение времени навигации нерепрезентативным. Подробности приведены ниже.

Приведённые цифры отражают результаты на определённый момент времени и будут меняться по мере выхода новых моделей. Каждый новый релиз влияет на то, как агенты ищут информацию, рассуждают и используют инструменты. Поэтому точные проценты неизбежно будут изменяться.

Именно по этой причине авторы приводят диапазоны значений, а не отдельные показатели для каждой модели. Однако общая закономерность сохранялась во всех экспериментах Netflix: каждый протестированный агент и каждая модель становились эффективнее.

Максимальный прирост демонстрировала самая мощная модель при высоком уровне вычислительных усилий, а масштаб улучшений заметно различался между моделями.

Задачи навигации по коду: эффективность выросла во всех случаях, корректность сохранилась или улучшилась

Все протестированные модели при любом уровне вычислительных усилий расходовали меньше токенов благодаря интеллектуальному анализу кода JetBrains IDE — без исключений.

Экономия составляла примерно от 15% до 60%.

Масштаб улучшений в основном зависел от модели: наиболее мощная демонстрировала значительно более высокие результаты, тогда как облегчённые конфигурации находились ближе к нижней границе диапазона.

Корректность в большинстве запусков не изменилась, а в двух случаях повысилась. Ухудшения не наблюдалось ни разу. При этом в задачах навигации обнаружилась одна особенность. Одна из комбинаций инструмента и модели уже умела объединять несколько поисковых запросов в одну команду. Поэтому независимо от наличия интеллектуального анализа JetBrains IDE агент выполнял только один вызов инструмента.

Единичное обращение к JetBrains IDE оказалось немного медленнее пакетной поисковой команды. Именно этим объясняется отсутствие выигрыша по времени в данной конфигурации. Однако такой результат не вполне отражает реальные сценарии использования. Поэтому для оценки экономии времени более надёжным ориентиром служат полноценные задачи полного цикла. В них интеллектуальный анализ JetBrains IDE ускорял работу всех протестированных моделей и агентов.

Задачи полного цикла: стабильное повышение эффективности без потери корректности

В расширенном наборе задач полного цикла корректность результатов оставалась неизменной для всех протестированных моделей и агентов. Следовательно, преимущество проявлялось исключительно в эффективности выполнения, а не в способности решить задачу.

Все комбинации моделей и агентов с интеллектуальным анализом JetBrains IDE работали примерно на 10–30% эффективнее с точки зрения времени выполнения и расхода токенов. Во многом это объясняется тем, что агентам требовалось меньше вызовов инструментов, чтобы прийти к тем же выводам.

Другие рассмотренные решения

Прежде чем выбрать описанный подход, Netflix отказалась от двух альтернатив.

Первой стал собственный внутренний CLI, который подключался к уже запущенному экземпляру IntelliJ IDEA для доступа к индексу проекта.

Принцип работы был похож на описанный в статье, но требовал постоянно работающей IDE. Такой подход не подходил для автономных агентов, работающих без графического интерфейса, в средах вроде Otto и Bitbot, инструментах распределённого рефакторинга, CI и других системах.

Вторым вариантом был существующий LSP-сервер Eclipse, который используется для поддержки Java в VS Code. Однако с системой сборки Netflix, основанной на Gradle, он попросту не заработал.

Что дальше

Дальнейшие планы Netflix

По итогам эксперимента Netflix пришла к выводу:

«Бенчмарки показывают, что наличие детерминированного слоя интеллектуального анализа кода наряду с агентом действительно приносит пользу».

Разумеется, это не означает, что каждая задача ИИ-агента будет выполняться быстрее на какой-то фиксированный процент.

Но для конкретной проблемы — определения реальной структуры кода и связей между его элементами, включая границы JAR-библиотек, — эффект оказался значительным, устойчивым для разных моделей и не сопровождался ухудшением корректности.

Netflix планирует применить ту же методику тестирования к Python, TypeScript/JavaScript и Go. Агенты, работающие с этими языками, сталкиваются с похожими проблемами. Однако механизмы загрузки библиотек и зависимостей различаются от языка к языку, поэтому и конкретные причины проблем, и возможные решения будут отличаться. JetBrains намерена продолжить сотрудничество и поддержать дальнейшие исследования.

Позиция JetBrains: LSP — лишь один из этапов, а не конечная цель

Технология интеллектуального анализа Java-кода JetBrains IDE прошла испытания в Netflix и теперь поставляется в составе расширения Java & Kotlin by IntelliJ IDEA.

JetBrains также продолжает эксперименты с подходом LSP + CLI и опубликует результаты, когда они будут готовы. Базовая единица, с которой работает LSP, — позиция в текстовом документе.

В спецификации позиция определяется как место «между двумя символами, подобно курсору ввода в редакторе». Для человека, работающего за клавиатурой, это естественный способ взаимодействия с кодом. Но агенты на самом деле не мыслят категориями расположения курсора.

Они задают вопросы о программе, например:

• «Почему этот вызов внутри createUser() не удаётся разрешить?»

• «Какие тесты покрывают этот метод?»

Иными словами, речь идёт о понимании связей между частями программы, а не о поиске определённых позиций в текстовом документе.

К тому же позиция в тексте — ненадёжный способ идентификации: достаточно вставить один символ перед указанным местом, и все последующие позиции сместятся. Агенту нужен не более точный виртуальный курсор, а слой, способный предоставлять ответы в терминах самих задач. То есть оперировать символами программы, диагностическими сообщениями, связями с тестами и поведением во время выполнения. И при этом возвращать достаточно контекста, чтобы агент мог осмыслить результат, а не просто получить координаты в текстовом файле.

«Именно это я подразумеваю под движком анализа кода. Не очередной протокол, позволяющий агенту имитировать взаимодействие с редактором, а набор точных операций над структурой программы и её выполнением, который возвращает достаточно контекста для полноценного анализа результата.

LSP полезен, но он не должен определять окончательную абстракцию для взаимодействия с агентами.

Если создавать инструменты для агентов так, словно агент — это маленький человек за текстовым редактором, мы вынуждаем его общаться на языке координат курсора.

Агентам нужен движок анализа кода, а не виртуальный редактор».

— Алексей Стукалов, руководитель подразделения разработки IDE в JetBrains

Результаты Netflix доказывают, что инвестиции в интеллектуальный анализ кода оправданны.

Теперь главная задача — определить, какую форму должны принять эти технологии в будущем.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.