IDE понимает ваш код. AI-агент — нет. Это можно исправить / Хабр

TL;DR: Ваша IDE знает о проекте всё — иерархии типов, ссылки между модулями, исходники библиотек, ошибки компиляции. AI-агент ничего из этого не видит и вынужден грепать код и логи. За один выходной можно написать плагин и CLI, которые выставят семантику IDE наружу — и агент получит те же суперсилы, что и вы. В статье — как это сделано на примере Eclipse и JDT, но подход переносим на любую IDE. Открытый код: github.com/kaluchi/jdtbridge.

Если ваши руки давно привыкли к Ctrl+Shift+G, Ctrl+T, Ctrl+Shift+T и сопротивляются переходу в другой редактор — вы, вероятно, в Eclipse. И вы точно знаете, что ваша IDE понимает код на уровне, который не снился ни одному AI-редактору. Но AI-агент об этом не в курсе, и как следствие, вынужден жечь десятки тысяч токенов на свои grep-ы.

Разрыв между IDE и агентом

Любая современная IDE даёт разработчику алгоритмически нетривиальный функционал: навигацию по иерархии типов, точный поиск ссылок с учётом перегрузок, инкрементальную компиляцию, рефакторинг с обновлением всех зависимостей, доступ к исходникам библиотек прямо из JAR-файлов. Вы нажимаете Ctrl+Shift+G — и за доли секунды получаете 8 точных call sites метода, а не 200 мусорных grep-совпадений.

А теперь посмотрите, что делает AI-агент, решая ту же задачу. Он грепает. Глобает по файлам. Получает 200 хитов, из которых нужны 8, и начинает вручную разбирать каждый, тратя ваш контекст и ваше время. Хочет проверить компиляцию — запускает mvn compile и грепает его логи. Хочет найти реализации интерфейса — ищет текст implements Repository, не подозревая о цепочках наследования. На эту примитивную возню невозможно смотреть — особенно когда IDE рядом уже давно всё проиндексировала.

И это не просто раздражает — это дорого. Каждый grep-запрос сжигает кэширующие токены, каждый ложный результат забивает контекстное окно мусором. На практике, если не выносить эту грязную работу в отдельные субагенты (Explore, CodeInvestigate), то основной агент не успевает сделать ничего полезного за одно контекстное окно — весь бюджет уходит на разведку, которую IDE выполнила бы мгновенно.

Не ждите — сделайте сами

Когда я начал работать с Claude Code, первым порывом было поискать готовый плагин, который бы связал агента с Eclipse. Готового тогда не нашлось. И я подумал: а почему бы не написать самому?

Есть принципиальная разница между инструментом, который вы используете как чёрный ящик — не мо��ете заглянуть внутрь, не можете расширить, ждёте обновлений от авторов — и платформой с открытым кодом и документированным API, которую можно разобрать, достроить и адаптировать под себя. Eclipse — это второе. JDT SearchEngine, рефакторинг, инкрементальный компилятор — всё доступно из Java-кода плагина. Нужно лишь выставить это наружу.

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

Как это устроено

Идея простая: Eclipse-плагин поднимает HTTP-сервер на loopback при старте IDE. Node.js CLI (jdt) автоматически находит запущенный Eclipse через файлы в ~/.jdtbridge/instances/ и транслирует команды из терминала в вызовы JDT API. Агент пишет jdt refs OrderRepository save — и получает 8 точных call sites вместо 200 мусорных grep-совпадений.

  Терминал / AI-агент              Eclipse IDE
+--------------------+         +--------------------+
|                    |  HTTP   |                    |
|   jdt CLI          | ------> |   JDT Bridge       |
|   (Node.js)        | JSON    |   плагин           |
|                    | <------ |     (JDT API)      |
+--------------------+         +--------------------+

Так появился JDT Bridge. Установка — три команды:

git clone https://github.com/kaluchi/jdtbridge.git
cd jdtbridge/cli && npm install && npm link   # глобальная команда jdt
jdt setup                                      # сборка + установка в Eclipse

jdt setup делает всё сам: собирает плагин через Maven, останавливает Eclipse если запущен, устанавливает через p2, перезапускает с тем же workspace.

Что это меняет на практике

Агент ищет вызовы метода. Раньше: grep, 200 хитов, 5 минут разбора. Теперь:

jdt refs com.example.dao.OrderRepository save --arity 1

8 строк. Файл, номер строки, содержимое строки. Точно те вызовы, которые нужны.

Агент хочет понять класс. Открывать 600-строчный файл и читать целиком? Необязательно:

jdt ti com.example.web.OrderController

Структурный обзор: поля, методы с сигнатурами, суперклассы, номера строк. Агент сразу видит API класса и знает, куда смотреть дальше.

Агент проверяет компиляцию. Вместо mvn compile и грепа его логов:

jdt err --project my-app-server

Доли секунды. Eclipse уже всё скомпилировал — агент видит ту же картину, что и вы.

Агент читает исходник Spring-класса — тот, что лежит внутри JAR и невидим для файловой системы:

jdt src org.springframework.transaction.support.TransactionTemplate execute

Агент получает ту же «go to definition» суперсилу, которая есть у разработчика в IDE.

А вот как это выглядит в терминале — публичные update-перегрузки Spring JdbcTemplate, отфильтрованные из полного списка методов двумя grep-ами:

Исходник Spring-класса из JAR, pipe-фильтрация, номера строк — в одной команде.

Почему CLI, а не MCP

Когда я начинал, MCP казался логичным выбором. Но быстро выяснилось, что CLI удобнее — и вот почему. MCP-вызов возвращает результат целиком в контекстное окно агента. CLI-вывод проходит через shell, и это всё меняет:

# В классе 65 методов, но нужны только операции с папками.
# MCP: все 65 в контекст. CLI: grep оставляет 27 нужных.
jdt ti com.example.dao.FileRepository | grep -i folder
# «Сколько мест вызова?» — число, а не 200 строк.
jdt refs com.example.core.Event dispatch | wc -l
# 47 ошибок, но чиним по одной. head -5 — и контекст не засорён.
jdt err --project my-server | head -5

Контекстное окно агента — конечный и дорогой ресурс. grep и head фильтруют до того, как данные попадут к агенту. Бесплатно. MCP-сообщество тоже это признаёт — token bloat от нефильтрованных результатов стал известной проблемой.

И ещё: один и тот же jdt работает и для агента, и для разработчика в терминале. Когда агент делает что-то странное, вы просто запускаете ту же команду руками и видите тот же результат. С MCP для этого пришлось бы поднимать отдельный клиент.

Что может пойти не так

Инструмент разрабатывался и проверялся на одной конфигурации: Windows 11, Java 21, Maven 3.9, Eclipse 2026-03. В тот момент в цели не входило делать его переносимым — я не тестировал на Linux, не проверял на других версиях JDK, и вся механика установки через p2 director вполне может оказаться хрупкой для вашего окружения. Если вы на IntelliJ — этот инструмент не подойдёт, хотя сам подход (выставить семантику IDE через CLI) переносим.

Но в этом и суть: у вас есть весь исходный код, тесты и AI-агент. Если что-то не заработает — просто попросите агента разобраться. Он справится.

Полный список команд

Для тех, кому интересны детали:

Команда	Алиас	Что делает
`references <FQN> [method]`	`refs`	Все ссылки на тип/метод/поле
`type-info <FQN>`	`ti`	Обзор класса (поля, методы, сигнатуры)
`source <FQN> [method]`	`src`	Исходный код (проект + библиотеки)
`errors [--project <name>]`	`err`	Ошибки компиляции
`implementors <FQN> <method>`	`impl`	Реализации метода интерфейса
`subtypes <FQN>`	`subt`	Все подтипы и реализации
`hierarchy <FQN>`	`hier`	Полная иерархия типов
`test <FQN> [method]`		Запуск JUnit-тестов
`find <Name>`		Поиск типов (`wildcards`)
`format <file>`	`fmt`	Форматирование (настройки Eclipse)
`organize-imports <file>`	`oi`	Организация импортов
`rename <FQN> <new>`		Переименование через весь workspace

Если ваш проект живёт в Eclipse и вы работаете с AI-агентами (или думаете начать) — попробуйте JDT Bridge. Установка — 3 команды, удаление — jdt setup --remove.

Буду рад вопросам и фидбеку — в комментариях или в issues. Если у вас есть свой опыт или наработки по этой теме — например, похожее решение для IntelliJ — поделитесь, интересно.