Netflix ускорила ИИ-агентов на Java: движок IntelliJ дал 20–30% экономии, до 65% в лучшем случае

Команды Netflix (Application Development Platform, GenAI Platform и Agentic SDLC) выяснили, сколько стоит отсутствие нормального понимания кода у ИИ-агентов. Они подключили к Claude Code и Codex безголовую версию движка кодовой аналитики JetBrains, того же, что лежит в основе IntelliJ IDEA. На реальных задачах агенты расходовали на 20–30% меньше токенов и времени, а в лучшем случае экономия достигала примерно 65%. Корректность результата при этом не падала ни в одном замере. Тесты шли в июле–августе 2026 года.

Проблема: JAR-файлы, в которых агент слепнет

В JVM-проектах библиотеки обычно поставляются в виде JAR-архивов без исходников. Агенту приходится самому распаковывать архивы, гадая, какие из них важны, при необходимости декомпилировать class-файлы и затем искать по этому неполному срезу через grep. Поиск получается медленным и ненадёжным, а токены уходят на блуждание. Пол Баккер, Staff Software Engineer в Netflix, описывает это так: агенты вроде Claude Code медленны и ненадёжны в навигации по Java/Kotlin, особенно на границах библиотек.

JetBrains годами строила детерминированный индекс исходников проекта вместе со всеми библиотеками. Теперь он доступен через LSP, в том числе в VS Code-совместимых редакторах. Но сам LSP для агента не готов: это сервер с протоколом, который нельзя просто вызвать из агента, к тому же нет управления процессами для повторного использования уже запущенного экземпляра.

Демон, который держит индекс тёплым

Построение индекса занимает ощутимое время, как первое открытие крупного проекта в IntelliJ IDEA. Агент же дёргает LSP множеством мелких шагов, и на одну задачу таких вызовов нужно несколько. Если каждый поднимает новый сервер, то каждый платит многосекундным холодным стартом, даже когда индекс был построен минуту назад.

Демона JetBrains на момент оценки ещё не выпустила, поэтому Netflix написала его сама:

• каждый вызов инструмента короткоживущий и без состояния, он просто обращается к CLI;
• менеджер сессий демона маршрутизирует вызов по корню проекта к нужному серверному процессу, который держит индекс в памяти;
• повторный вызов по тому же проекту пропускает индексацию и идёт к «тёплому» серверу по stdio;
• демон и CLI написаны на Java и распространяются как исполняемый файл GraalVM, так что накладных расходов JVM на старт нет.

Как мерили и что получилось

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

• внутренний продакшен-сервис среднего размера на Spring Boot 4 и Gradle;
• открытый DGS Framework от Netflix, смешанный Kotlin/Java GraphQL-фреймворк.

Задачи делились на два типа. Первый — небольшие навигационные: где используется интерфейс, какие у него реализации, какова структура класса. Второй — сквозные: реализовать фичу, отрефакторить класс, удалить код. Конфигурации агентов и моделей:

• Claude Code с Opus 5 (medium/high effort);
• Claude Code с Sonnet 5 (medium/high effort);
• Codex с GPT-5.6 Sol (medium/high effort).

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

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

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

Что отвергли и куда двигаться

До финального решения Netflix отбросила два варианта. Первый — собственный внутренний CLI, подключавшийся к запущенной IntelliJ IDEA: он требует открытой IDE и не подходит для безголовых сред вроде Otto, Bitbot, инструментов распределённого рефакторинга и CI. Второй — Eclipse LSP, который используют для Java в VS Code: с Gradle-сборкой Netflix он просто не заработал.

Дальше компания прогонит ту же методологию на Python, TypeScript/JavaScript и Go, где у агентов похожие проблемы, хотя механика загрузки библиотек в этих экосистемах другая. JetBrains уже выпустила Java-интеллект, протестированный Netflix, в составе расширения Java & Kotlin by IntelliJ IDEA, а эксперименты с подходом LSP+CLI продолжает.

Алексей Стукалов, руководитель IDE-направления JetBrains, указывает на слабое место самого LSP: его базовый примитив — позиция курсора в тексте, а агенты думают символами, диагностиками, связями тестов и поведением в рантайме. Позиция в тексте хрупка, она сдвигается от одной вставленной буквы. По его словам, агентам нужен не виртуальный редактор, а код-движок с точными операциями над структурой программы.

Для команд, которые уже платят за агентов на JVM, вывод практичен. Если токены на сильных моделях составляют заметную статью расходов, детерминированный слой кодовой аналитики рядом с агентом окупается быстрее, чем апгрейд модели. Но готового демона в коробке пока нет: его придётся собирать самим по схеме Netflix или ждать релиза JetBrains.