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-агент. Если что-то не заработает — просто попросите агента разобраться. Он справится.
Полный список команд
Для тех, кому интересны детали:
Команда |
Алиас |
Что делает |
|---|---|---|
|
|
Все ссылки на тип/метод/поле |
|
|
Обзор класса (поля, методы, сигнатуры) |
|
|
Исходный код (проект + библиотеки) |
|
|
Ошибки компиляции |
|
|
Реализации метода интерфейса |
|
|
Все подтипы и реализации |
|
|
Полная иерархия типов |
|
Запуск JUnit-тестов |
|
|
Поиск типов ( |
|
|
|
Форматирование (настройки Eclipse) |
|
|
Организация импортов |
|
Переименование через весь workspace |
Если ваш проект живёт в Eclipse и вы работаете с AI-агентами (или думаете начать) — попробуйте JDT Bridge. Установка — 3 команды, удаление — jdt setup --remove.
Буду рад вопросам и фидбеку — в комментариях или в issues. Если у вас есть свой опыт или наработки по этой теме — например, похожее решение для IntelliJ — поделитесь, интересно.
Комментарии (22)
HRYN
09.03.2026 19:32Интересный подход. По сути это то же самое что MCP, только через CLI
Kaluchi Автор
09.03.2026 19:32Да, с обычным CLI не нужно сочинять и расписывать все эти фильтрующие/лимитирующие параметры для каждой команды с теоретически большим выводом -- агенты обычно сами подстраховывают tail/head-ами. С CLI не нужен MCP Inspector и т.п. отладочные инструменты. CLI есть у докера, авс, сентри, гитхаба и т.д. --- и агенты с ними прекрасно ладят. Просто MCP создан для немного для другого уровня интеграции (когда у агента нет баша), а когда терминал есть -- то CLI-утилита/скрипт это более подходящий способ расширения функционала агента: нет проблем с раздутым описанием инструментов -- не рассказал агенту - он и не знает ничего, а когда задача требует навыка -- то просто используешь скилл, в котором описано, как пользоваться твоими CLI/скриптами. Все просто.
YauheniyaKl
09.03.2026 19:32Интересно, спасибо. Откликнулась мысль, что агент зря тратит контекст на то, что IDE уже умеет делать. Есть ли в планах поддержка безопасных рефакторингов через CLI, чтобы перед применением можно было посмотреть preview изменений?
Scalar
09.03.2026 19:32А почему бы не запустить Language Server (jdt или любой другой) и натравить агента на его API ?
Antra
09.03.2026 19:32Вот реально. Есть же куча Language Server. В том же VS Code сама IDE фактически через него работает. В чем проблема (если правда есть) его "дернуть"?
Да и насчет "грепает" несколько странно. Даже если не говорить про встроенные индексации (Antigravity и т.п.), даже сторонние расширения такое давно уж делают. В тот же RooCode уж больше года, мне кажется, я подключение к embedding (причем на домашней машине, ресурсов-то не тратится практически) и Qdrant активировал.
Неужто все равно катастрофически неэффективно? Или это особенность Eclipse?
house2008
09.03.2026 19:32Спросил гпт, говорил в зависимости от запроса использует разные техники. Попросил его найти использование метода в Swift и он искал грепом и вот что потом написал когда спросил про AST/LS
Tools actually used
• grep
• find
• nl
• sed
Not used
• SourceKit
• AST inspection
• compiler index / build system
I did not need SourceKit or AST here because the method name is specific enough that a repository-wide text search produced a complete, low-noise result set.Kaluchi Автор
09.03.2026 19:32В Claude Code несмотря на буквальную формулировку в его системном промте: "Do NOT use the Bash to run commands when a relevant dedicated tool is provided" - я регулярно вижу, как модель скатывается к sed, awk, echo >, cat <<EOF и разным самопальным python-скриптам, когда внезапно нарывается на проблемы со вставкой своих патчей или вопросы с кодировками/переносами строк. Это очень раздражает ещё и потому, что клод код тогда требует явного подтверждения действия от пользователя. А с его однопотончной хук моделью это означает, что и другие агенты в это время ждут в очереди, что бы продолжить работу. Из-за этого невозможно отойти от монитора даже на пару минут. Один запутавшийся агент блокирует всех остальных.
house2008
09.03.2026 19:32Согласен, та же история - по логам постоянно юзает греп, ни разу не видел чтобы лез в анализ скомпилированного/промежуточного кода, всегда грепает. Мне понравилось, что сделал автор статьи, но у себя со Swift не смог повторить - очень сложно вытащить нужную информацию из SourceKit + нужно всегда синхронизировать/актуализировать индексацию при каждом запросе, хотел глянуть SLP так там вообще мрак самому всё писать и разбираться. Пет проект небольшой, пока и грепа хватает, но для большого видимо нужно прикручивать что-то помощнее что ниже писали про Serema MCP.
ApeCoder
09.03.2026 19:32Serena mcp
Kaluchi Автор
09.03.2026 19:32Плюсанул. Это движение в правильном направлении, особенно, когда речь идет про полную автономность агентов.
Но для парной работы в специализированных средах -- и, особенно, когда вокруг все LLM-вендоры борются с тем, что бы их подписку не использовали в "самопальных" решениях и конкурентах (Opencode, OpenClaw и т.д.), когда уже начата открытая война с создатеями альтернативных агентных сред (зачастую гораздо более качественных, чем тот же Антигравити или Клод Код) -- не получится придумать ничего более естественного, чем CLI-шлюз к процессу твоей программы.
И дело ещё в cвободе, неохота оказаться в ситуации, как с ремонтом тракторов John Deere/заправкой картриджей HP -- когда ты, купив вещь, становишься рабом её дилера. И не можешь там даже лампочку поменять, без риска потери гарантии.
Kaluchi Автор
09.03.2026 19:32Спасибо за отзыв. LSP (или любой другой отдельный вычислительный процесс на стороне) был отброшен на ранней стадии — он не подходил под задачу. Мне нужно было вытаскивать информацию из процесса именно моей IDE. Нужны были именно её маркеры компиляции, её чекстайл, её тест-лаунчер и так далее. Отдельный Language Server — это отдельный индекс, отдельный build state, и он неизбежно рассинхронизируется с тем, что вы видите в IDE.
LSP — слишком низкоуровневая вещь, заточенная под редактор. Это протокол не для людей и не для агентов. textDocument/references с позиционными координатами в JSON-RPC — попробуйте это отдебажить руками. Даже если вы его как-то подключите — не факт, что ваша модель захочет этим пользоваться и не соскочит на свои фолбэки после первой же неудачи. Кто хоть немного поработал с кодинг-агентами — тот сразу поймёт, о чём речь. Модель нужно ещё убедить, что данный инструмент лучше и полезнее, чем то, на чём её тренировали. Агент обучен на grep/find, он к ним тянется рефлекторно. CLI с понятными командами (jdt refs, jdt err) имеет куда больше шансов быть подхваченным моделью, чем LSP JSON-RPC.
rdin777
09.03.2026 19:32Интересный кейс. Как специалист по ИБ, сразу задумываюсь о поверхности атаки при такой глубокой интеграции агента с IDE через внешние API. Если агент получает доступ к управлению "извне", это создает дополнительные риски внедрения вредоносного кода через промпты или компрометацию самого канала управления. Кто-нибудь уже задумывался о песочницах для таких агентов внутри IDE?
Kaluchi Автор
09.03.2026 19:32Десятки всяких песочниц уже есть. Начиная с docker sandobx и gVisor (на которых облачный клод код работает) и заканчивая всякими менее распространенными вариантами.
okhsunrog
09.03.2026 19:32https://code.claude.com/docs/en/discover-plugins
Есть же плагинjdtls-lsp
Разве его недостаточно?Kaluchi Автор
09.03.2026 19:32jdtls-lsp -- полезная вещь для автономных сценариев, когда агент работает один, без IDE, с чистого листа. Но в парной работе, когда Eclipse уже запущен и настроен -- форматтер, чекстайл, тест-лаунчер, свои чекеры, плагины -- всё под проект. Поднимать рядом ещё один headless Eclipse с отдельным индексом потом избыточно. Это как третья нога при ходьбе.
Всё, что даёт LSP-плагин (диагностика, навигация), в IDE уже есть и работает точнее, потому что это ваш настроенный workspace. JDT CLI Bridge просто выставляет это наружу.
К слову, про jdtls-lsp -- типичная ситуация: https://github.com/anthropics/claude-code/issues/17643 — на Windows плагин не работает из-за обратных слешей в file:// URI. Баг открыт, подтверждён множеством пользователей, воспроизводится до последней версии -- и тишина. Один из комментаторов https://github.com/anthropics/claude-code/issues/17643: "These are not edge cases, these are basic smoke test type defects." При 5500+ открытых issues в репозитории Claude Code ждать починки можно долго — проще сделать самому.
diffnotes-tech
09.03.2026 19:32jdt внутри Explore субагента был бы идеальной связкой. Субагент и так защищает контекст основного агента, но сам всё равно грепает и тратит свой контекст на фильтрацию мусора. С jdt субагент получает 8 точных результатов сразу и возвращает основному агенту сухой остаток
Kaluchi Автор
09.03.2026 19:32Есть ещё неочевидный, ускользающий от внимания большинства момент про стоимость. Каждый tool call агента отправляет в API весь накопленный контекст -- все предыдущие запросы и ответы. Первый вызов -- 3k токенов, десятый -- уже 30k, двадцать пятый -- 65k. Это арифметическая прогрессия, сумма растёт квадратично от числа итераций.
Prompt caching снижает стоимость пересчёта, но за передачу кэшированных токенов всё равно нужно платить. Квадратичность остаётся. O(n²) живёт в протоколе, это следствие stateless HTTP-API и накопления контекста. Чем больше итераций нужно инструменту -- тем дороже каждый следующий шаг.
Забить итерациями до отсечки окно 200к Opus-a обходится примерно в 30 у.е., а сделать то же самое в 1M окне -- это уже 700 у.е.. Разница по бюджету ×23, а не ×5. Просто сейчас вендоры активно субсидируют расходы пользователей. Но эта щедрость не вечна и не бесконечна.
Micha1l
09.03.2026 19:32Доброго дня, я не профессиональный программист но тоже хотел бы сэкономить токены на вайбкодинге пет проектах.
Облачные IDE вроде Google Antigravity избавлены от такой проблемы?
И какие есть ещё более оптимизированные инструменты без сложных настроек? Заранее благодарю!
LuciusWill
Я думал, именно в таком виде агенты и работают с IDE. Похоже, есть ещё много работы по нормальной интеграции и организации работы агентов.
Kaluchi Автор
Да, такой подход работает для любого софта, который позволяет собрать себя из исходников или расширить плагинами. Если у инструмента есть API — внутренний, плагинный, какой угодно — этого достаточно, чтобы вытянуть из него нити управления наружу и сделать доступным для агента. По сути, это универсальный рецепт пульта дистанционного управления для чего угодно.