IDE не для людей: как JetBrains переучивает IntelliJ работать с AI-агентами

Пока все спорят, нужна ли IDE вообще, JetBrains тихо меняет вопрос: не «нужна ли IDE человеку», а «что IDE может дать агенту». Разбираем, что из этого получается на практике — с цифрами по токенам, латентности и стоимости.

Почему «агент + терминал» упирается в потолок

Стандартный стек coding-агента выглядит так: grep, bash, edit, пара хороших промптов — и вперёд. Для простых задач этого хватает. Но как только задача усложняется — найти все вхождения метода с учётом типов, безопасно переименовать класс, запустить конкретный тест и посмотреть покрытие — агент начинает делать то, что делает любой джун без IDE: читает всё подряд, строит контекст вручную и сжигает токены на шум.

Проблема не в агенте — проблема в инструментах. grep не знает границ символов и семантики языка. Он вернёт все строки, где встречается слово getUserById, включая комментарии, строки в тестах и случайные совпадения в конфигах. Агент получает грязный вывод и делает дополнительные вызовы, чтобы его отфильтровать. Это и есть та самая «россыпь shell-команд» вместо среды разработки.

Что JetBrains предлагает агенту вместо grep

Идея JetBrains простая: дать агенту доступ к тем же инструментам, которыми пользуется разработчик внутри IDE, — через MCP (Model Context Protocol). Один MCP-tool закрывает сразу несколько режимов поиска:

• поиск файлов по имени и паттерну
• текстовый поиск по содержимому
• regex-поиск
• поиск символов (классы, методы, поля) с учётом структуры языка

Вместо того чтобы агент сам собирал пайплайн из нескольких shell-вызовов, он делает один вызов к IDE-native инструменту и получает структурированный, чистый результат. Дальше идёт skill — набор инструкций, который объясняет агенту, когда вызывать этот tool, какие параметры передавать и как интерпретировать ответ.

Архитектурно это выглядит так:

`` Агент → Router (skill) → единый MCP-tool → IDE Search API → структурированный результат ``

Router решает, какой режим поиска нужен в конкретной ситуации, и передаёт запрос дальше. Агент не думает о том, что использовать — grep или find, — он просто описывает, что ищет.

Что показали тесты: цифры по латентности и стоимости

JetBrains провели сравнение конфигурации с IDE-native поиском против baseline (чистый shell-поиск) по четырём метрикам:

• Quality — прошли ли все тесты
• Latency — медиана и P95 времени выполнения задачи
• Cost — расход токенов, переведённый в доллары
• Budget discipline — как часто одна задача превышает лимит в $0.50

Результат: латентность и стоимость снизились, quality статистически значимо не изменилось. То есть агент стал дешевле и быстрее — без потери качества.

Дополнительно проверили на GPT 5.4 с Java- и Kotlin-проектами. Улучшения воспроизвелись на обеих моделях. Сильнее всего упала стоимость на Kotlin — минус 13.48%. Это объяснимо: Kotlin-проекты часто содержат больше extension-функций и вложенных лямбд, где grep особенно плохо справляется с поиском символов.

Где это уже применяется: тесты и покрытие

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

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

Где это ломается

Поддержка стека. IDE-native инструменты работают там, где IDE понимает язык. Для Java и Kotlin всё хорошо. Для нестандартных DSL, конфигов или смешанных монорепозиториев поиск символов может давать неполные результаты.

Версионирование skills. Skill — это инструкция для агента. Если API инструмента меняется (а у JetBrains это происходит), skill нужно обновлять вручную. Без процесса распространения обновлений внутри команды вы быстро получаете зоопарк локальных версий.

Latency на старте. IDE должна быть запущена и проиндексирована. Если агент работает в CI-окружении без прогретой IDE, первый вызов MCP-tool будет медленным или вовсе упадёт.

Budget discipline не решается инструментом. Даже с IDE-native поиском агент может уйти в петлю, если задача плохо сформулирована. Инструмент снижает стоимость одного вызова, но не контролирует их количество.

Что попробовать дальше

Если хотите воспроизвести этот подход у себя:

1. Посмотрите на MCP-интеграцию JetBrains — она доступна через плагин и поддерживает IntelliJ-based IDE.
2. Начните с search skill как самого простого кейса — он даёт измеримый результат без сложной настройки.
3. Дальше имеет смысл смотреть в сторону debugger-инструментов и coverage API — это следующий уровень IDE-native окружения для агента.
4. Следите за проектом OpenIDE — команда развивает ту же идею независимо от JetBrains и публикует результаты экспериментов.

IDE никуда не делась. Она просто меняет пользователя.

Источники

• Habr AI: JetBrains IDE: будущее не за горами