Если вы хоть немного следите за AI coding, то наверняка слышали новую мантру: IDE больше никому не нужна. Все «вайбанутые» живут в терминале, запускают Claude Code, Codex или OpenCode и уверенно объясняют, что профессиональная среда разработки — это пережиток эпохи, когда код писали руками.

Agent-у хватает самых простых инструментов: grep, bash, edit и пары хороших prompt-ов. Сложные интерфейсы, UI-инспекторы, рефакторинги, дебаггер — всё это выглядит как пережиток прошлого. Открыл терминал, написал задачу, получил diff. Кажется, человечеству IDE больше не нужна. Или всё-таки нужна? Тут как посмотреть.

JetBrains в этой картине обычно достаётся роль динозавра. Компания много лет задавала планку того, как должен выглядеть профессиональный инструмент разработчика. Но когда индустрия сместила фокус с IDE на agent-ов, предложенные JetBrains AI Chat (ex. AI Assistant) и Junie выглядели не как новый тренд, а скорее как попытка заскочить в уходящий поезд.

Но у тезиса «IDE больше не нужна» есть слабое место: он смотрит на IDE только глазами человека. А что, если следующими пользователями IDE будут не люди, а agent-ы? В компании JetBrains с закатом IDE, естественно, не согласны и предлагают своё видение: среда разработки как набор инструментов и знаний о проекте, доступных AI Agent-у.

Команда OpenIDE здесь придерживается схожей позиции: мы считаем, что IDE никуда не денется. На данный момент ни один разработчик, которого я знаю, не удалил IDE с рабочего компьютера, хотя agent-ами пользуются уже все или почти все.

Но сегодня поговорим не о том, зачем IDE нужна человеку и почему от неё не отказываются, а о том, зачем IDE нужна agent-у.

IDE for AI Agent

Сразу договоримся о терминах. Когда я говорю об IDE для AI Agent-а, я имею в виду не среду, в которой человек общается с agent-ом. Не Air, не Claude Code и не очередную chat-панель внутри редактора. Я говорю об Integrated Development Environment в буквальном смысле: о наборе инструментов и знаний о проекте, которыми Agent может пользоваться для решения поставленной задачи.

На первый взгляд это звучит контринтуитивно. Зачем Agent-у IDE, если он и так неплохо справляется с задачами через Grep, Bash, Edit и Find? Но тут полезно вспомнить, как работает обычный разработчик. Когда нужно просто найти строку в проекте, grep действительно достаточно. Когда нужно понять связи между классами, пройти по references, безопасно переименовать метод, запустить конкретный тест или посмотреть состояние приложения в debugger-е, мы почти всегда обращаемся к IDE.

С Agent-ами происходит то же самое. Базовый набор tool-ов закрывает простые сценарии, но как только вы захотите научить Agent-а профилировать приложение или дебажить тесты, вам понадобятся новые tool-ы. А к ним сразу понадобятся skill-ы, которые объясняют, когда эти tool-ы вызывать, какие параметры передавать и как интерпретировать результат.

Дальше начинается знакомая история. Вы добавляете tool, пишете под него skill, потом ещё один tool, потом ещё один skill, затем чините edge case-ы, обновляете инструкции после изменения API, договариваетесь о формате вывода. Через некоторое время у вас появляется то самое окружение разработки для AI Agent-а. Только теперь его нужно поддерживать: обновлять tools & skills, тестировать, распространять внутри команды, собирать обратную связь и следить, чтобы всё это не превращалось в набор локальных «костылей».

По сути, IDE всегда решала именно эту задачу: давала готовое окружение под конкретный стек, только пользователем был человек. Теперь тот же вопрос встаёт для AI Agent-а. Можно ли дать ему не россыпь отдельных shell-команд, а полноценную среду с поиском, навигацией, refactoring-ами, запуском тестов и debugger-ом?

Это направление мы видим одним из ключевых для OpenIDE. Давайте посмотрим, как с этой задачей справляется JetBrains.

IDE-Native Search Tools

Когда coding-агентам нужно искать по коду, в подавляющем большинстве случаев они использую shell-инструменты. grep и find работают, но слепы к структуре проекта, границам символов и семантике языка — agent сжигает токены, просеивая шумный вывод и делая дополнительные вызовы, чтобы сузить поиск.

Что, если попробовать очевидное и дать агент возможность пользоваться встроенным поиском в IDE?

Возьмем skill от JetBrains, который связывает поисковый промпт с единым MCP-tool; тот, в свою очередь, позволяет выполнять поиск файлов, текстовый поиск, regex и поиск символов.

Для сравнения отслеживаем четыре метрики: quality, latency, cost и budget discipline. Quality показывает, прошли ли все тесты; latency — медиану и P95 времени выполнения задачи; cost — расход токенов, переведённый в доллары; budget discipline — как часто одна задача превышает лимит в $0.50.

Как раз такой тест провели в компании JetBrains, посмотрим на результаты.

Результаты

Выбранная конфигурация — готовый search skill, единый IDE-native tool и универсальный router. По сравнению с baseline без IDE-native поиска она снизила latency и cost, при этом quality статистически значимо не изменилась.

Разница видна по тому, как меняется путь поиска по проекту.

Cross-Model Validation

Улучшения сохраняются на разных моделях и стеках. Ниже — результаты для GPT 5.4 на Java- и Kotlin-проектах: latency и cost снизились, а сильнее всего cost упал на Kotlin — на 13.48%.

Code Coverage

Рано или поздно, программируя с AI Agent-ом, вы осознаёте необходимость и важность тестов. Естественно, основную массу этих тестов Agent будет писать за вас.

Чтобы понять, куда этот тест положить, Agent-у приходится восстанавливать структуру проекта. Он смотрит имена файлов, проверяет папки, ищет похожие методы и читает соседние тесты — всё ради того, чтобы понять, как в проекте принято тестировать такой код. Токены при этом улетают быстро.

Когда Agent-у нужно добавить тест, вопрос не только в том, что именно проверять. Ему ещё нужно понять:

1. Где в этом проекте обычно лежат тесты на такой код?

2. Какие существующие тесты уже покрывают соседний код?

3. Какой testing framework, naming convention и стиль assertion-ов приняты в проекте?

4. Есть ли уже тестовый файл, который логичнее дополнить, а не плодить новый?

Человек часто знает это по опыту или быстро считывает по структуре проекта. AI Agent-у обычно приходится выяснять это более дорогим путём: через поиск, чтение соседних файлов и дополнительные уточняющие шаги.

finding-tests skill

Чтобы не собирать этот контекст каждый раз через хаотичный поиск по кодовой базе, JetBrains подготовила новый skill — finding-tests. Он поставляется в двух вариантах: как bundled skill для AI Assistant и как отдельный MCP-tool (findTests) для внешних agent-ов вроде Claude Code или Codex.

Идея простая: в IDE уже есть мощный coverage analysis. Поэтому, когда AI Agent-у нужно понять, где тестируется тот или иной код, ему не приходится выводить эту связь только из имён папок и результатов поиска.

Разберемся на примере IDE Rider для .Net

Rider использует данные о coverage от dotCover, чтобы определить, какие тесты связаны с кодом, над которым работает Agent. Так данные превращается в контекст для AI-сгенерированных тестов.

Вот как workflow выглядит под капотом:

• Агент решает, что нужен тест. Когда AI пишет новый код, меняет существующее поведение или вы явно просите добавить test, в работу включается skill finding-tests.

• Rider запрашивает coverage context у dotCover. dotCover прогоняет тесты из solution и строит coverage data вокруг кода, с которым работает Agent.

• Находится правильное место для теста. Поскольку Rider знает, какие тесты уже покрывают соседний код, он возвращает путь к подходящему тестовому файлу — без ручного поиска по проекту.

• Агент следует вашему стилю тестов. Agent получает нужный файл, читает окружающие тесты и генерирует тест, который вписывается в существующую кодовую базу.

Результат: стоимость токенов снижается вдвое

Это не просто улучшение удобства. Такой контекст заметно влияет и на workflow, и на бюджет.

✂️ Расходы на токены сокращаются на 50%.

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

Во внтуренних benchmark-ах JetBrains, прямой переход к нужному файлу сокращал потребление токенов до 50%.

Проще всего понять, почему так происходит, на одной показательной траектории. На изображении ниже приведён пример траектории Agent-а для простой задачи в проекте Kavita: добавить coverage для SeriesExtensions.GetCoverImage в районе строк 79-80. Модель и кодовая база в обоих вариантах были одинаковыми. Отличался только доступ к Rider coverage context: мог ли Agent перед началом работы спросить IDE, какие тесты уже покрывают этот метод.

Профит не только в том, что вы меньше тратите на AI. Для команд с quota-based доступом или общим пулом AI credits это ещё и снижение расходов на поиск и исследование проекта. Значит, большая часть вашего AI бюджета остаётся на более ценные задачи разработки.

Profiling

Рассмотрим ещё один пример: приложение зависает на десять секунд, и вы спрашиваете AI Agent-а, что пошло не так. Что происходит дальше? Agent анализирует код, строит догадку и приступает к редактированию. Решит ли написанный код описанную проблему? Вероятность примерно 50 на 50: может, решит, а может, и нет.

Для решения таких задач разработчики используют profiler: он позволяет точно понять, куда ушло CPU-время. Однако Agent-у он недоступен. В результате остаётся единственный путь: анализировать проект, находить правдоподобные неэффективности и принимать их за bottleneck. Иногда это срабатывает, но на настоящем freeze — обычно нет.

Команда Rider предлагает помочь Agent-у, предоставляя profiling skill на базе dotTrace — dottrace-analyze. Идея простая: вы отдаёте Agent-у .dtp snapshot, уже снятый через dotTrace — standalone profiler, command-line tool или dotTrace внутри Rider, — и вместо анализа исходников вслепую он сначала читает profile. Skill показывает, куда на самом деле ушло время, ведёт hot path обратно в ваш код и объясняет, что тормозит и почему, с рекомендациями, куда смотреть дальше.

Дальше приведены результаты benchmark-ов JetBrains по методике LLM-as-judge. Оценивалось, выявил ли Agent основной проблемный участок, объяснил ли механизм проблемы, избежал ли вводящих в заблуждение отклонений и предложил ли исправление, которое следует из имеющихся данных.

UI-freeze, который агент не нашёл без dotTrace

Одним из тестовых сценариев была ранняя версия Avalonia, которая зависала при shutdown. Похожая проблема пару лет назад попадала и в сам Rider — хороший пример того, как легко performance degradation из популярных open source проектов может просочиться в ваши приложения.

В JetBrains специально тестировали версию Avalonia до фикса в AvaloniaUI/Avalonia#16633. Было важно взять известный, уже исправленный bug, чтобы у eval-а был чистый пример решения.

Одного и того же Agent-а запускали на этой проблеме десять раз со skill-ом и десять раз без него, а затем просили LLM-judge оценить каждый диагноз относительно известной root cause по шкале от 0 до 10.

Без skill-а Agent в среднем набрал 1.6 из 10. Он уходил в rendering-код, перечислял общие рекомендации и так и не добирался до реальной причины.

Со skill-ом результат был 10 из 10 в каждом из десяти запусков.

В результате добавления skill-а мы получили Agent-а, который стабильно находит причину проблемы.

При этом такие проблемы действительно сложно найти простым чтением кода, даже если у вас есть пара свободных часов. Freeze не находился в одном очевидном месте. Он возникал из-за посимвольной операции глубоко в text layout path: сама по себе она дешёвая, но выполнялась столько раз, что съедала большую часть CPU. Эта цена становится видна только тогда, когда понятно, куда на самом деле ушло время. Snapshot привёл Agent-а прямо к проблеме: он объяснил, почему операция оказалась такой дорогой, и указал на изменение, которое её исправляет.

Полный бенчмарк: восемь сценариев, 80 запусков

Сценарий с Avalonia был лишь одной частью оценки. После повторных запусков набор расширили до восьми сценариев расследования performance-проблем в .NET из разных проектов и сравнили одного и того же Agent-а с доступом к profiler-у и без него. Вот как skill изменил средний показатель точности в каждом сценарии по шкале из 10 баллов:

По всем 80 запускам средний показатель точности вырос с 4,71 до 8,15. Число запусков с оценкой 8 и выше почти удвоилось — с 29 до 59. Запусков, в которых root cause была определена точно, стало более чем вдвое больше: 48 вместо 20.

В этой таблице есть два момента, о которых стоит сказать отдельно.

Первый — skill по настоящему окупается в сценариях, где базовый вариант был безнадёжен. Там, где ответ находился в runtime-данных, например в зависании Avalonia или нагрузке Cyclops, базовый вариант набирал 1–2 балла, а skill поднимал результат до 9 или 10. Agent переставал распыляться на общие идеи оптимизации и удерживался на том, что действительно тормозило.

Второй — нижняя часть таблицы. game-of-life, checkers-copy и checkers-update уже хорошо решались без profiler-инструментов, а в двух случаях с checkers skill снизил оценку на несколько десятых. Вывод не в том, что skill ухудшает результаты, а в том, что некоторые задачи в нём не нуждаются. Иногда запускать полноценный profiling workflow там, где достаточно быстро посмотреть на код, — это просто пустая трата токенов.

Сколько это на самом деле стоит

Начнём с очевидного: работа с профайлером — это реальная работа. Agent загружает данные profiler-а, проходит по деревьям вызовов и связывает доказательства с исходным кодом, прежде чем перейти к рассуждению. В серии из 80 запусков это отразилось на счёте: стоимость выросла примерно с 1,91 доллара за запуск без skill-а до 2,61 доллара со skill-ом. Общая стоимость серии составила около 153 долларов без skill-а и 209 долларов со skill-ом. Учитывая, насколько улучшилась диагностика, это выглядит как хороший trade-off, но рост затрат реален, и о нём лучше сказать прямо.

Но есть и второй эффект, работающий в обратную сторону. В дополнительном тестовом случае с Avalonia — приложении, которое медленно завершало работу, — Agent без skill-а так и не нашёл настоящую причину. В десяти запусках он снова и снова строил одну и ту же правдоподобную, но неверную теорию, широко искал по проекту и просматривал файл за файлом, каждый раз получая 0 из 10. Со skill-ом он сначала использовал данные profiler-а, сразу вышел на нужный path в коде и получил 10 из 10. Отказ от этих лишних поисковых шагов сделал запуски дешевле и быстрее: 2,58 доллара за запуск вместо 3,74 доллара и 206 секунд вместо 373.

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

Заключение

Результаты, полученные JetBrains, похожи на результаты OpenIDE на внутреннем benchmark-е. Как и JetBrains, команда OpenIDE считает направление IDE for AI Agents одним из ключевых. Поэтому набор инструментов OpenIDE, доступных AI Agent-у, будет только расширяться.

Amplicode, входящий в базовую поставку OpenIDE, уже включает Spring Skills и Spring MCP. Вместе они дают хорошую поддержку для Spring-разработчиков:

• анализ Spring-приложения с учётом архитектуры, в том числе DDD;

• понимание Spring Data JPA: настройка модели, работа с репозиториями и транзакциями;

• работа с DTO и мапперами, включая MapStruct и ModelMapper;

• конфигурация Spring Security;

• создание CRUD REST и настройка Spring MVC;

• отладка приложения с помощью Agent-а.

А что дальше? Провести схожие эксперименты на меньших моделях. Гипотеза в том, что они выиграют от IDE-native инструментов ещё больше, поскольку у них меньше встроенных возможностей поиска, на которые можно опереться.

На текущий момент самые сильные результаты получены для Java, Kotlin и .NET. В планах — расширение набора стеков и поддержка Python, Go и TypeScript.

Чтобы оставаться на связи, следить за новостями и ничего не пропустить, подписывайтесь на OpenIDE: в Telegram или на YouTube.