Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 34
Я думал, именно в таком виде агенты и работают с IDE. Похоже, есть ещё много работы по нормальной интеграции и организации работы агентов.
Да, такой подход работает для любого софта, который позволяет собрать себя из исходников или расширить плагинами. Если у инструмента есть API — внутренний, плагинный, какой угодно — этого достаточно, чтобы вытянуть из него нити управления наружу и сделать доступным для агента. По сути, это универсальный рецепт пульта дистанционного управления для чего угодно.
Интересный подход. По сути это то же самое что MCP, только через CLI
Да, с обычным CLI не нужно сочинять и расписывать все эти фильтрующие/лимитирующие параметры для каждой команды с теоретически большим выводом -- агенты обычно сами подстраховывают tail/head-ами. С CLI не нужен MCP Inspector и т.п. отладочные инструменты. CLI есть у докера, авс, сентри, гитхаба и т.д. --- и агенты с ними прекрасно ладят. Просто MCP создан для немного для другого уровня интеграции (когда у агента нет баша), а когда терминал есть -- то CLI-утилита/скрипт это более подходящий способ расширения функционала агента: нет проблем с раздутым описанием инструментов -- не рассказал агенту - он и не знает ничего, а когда задача требует навыка -- то просто используешь скилл, в котором описано, как пользоваться твоими CLI/скриптами. Все просто.
Интересно, спасибо. Откликнулась мысль, что агент зря тратит контекст на то, что IDE уже умеет делать. Есть ли в планах поддержка безопасных рефакторингов через CLI, чтобы перед применением можно было посмотреть preview изменений?
А я вам больше скажу. Я даже вручную иногда прогроммировываю!
А почему бы не запустить Language Server (jdt или любой другой) и натравить агента на его API ?
Вот реально. Есть же куча Language Server. В том же VS Code сама IDE фактически через него работает. В чем проблема (если правда есть) его "дернуть"?
Да и насчет "грепает" несколько странно. Даже если не говорить про встроенные индексации (Antigravity и т.п.), даже сторонние расширения такое давно уж делают. В тот же RooCode уж больше года, мне кажется, я подключение к embedding (причем на домашней машине, ресурсов-то не тратится практически) и Qdrant активировал.
Неужто все равно катастрофически неэффективно? Или это особенность Eclipse?
Спросил гпт, говорил в зависимости от запроса использует разные техники. Попросил его найти использование метода в 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.
В Claude Code несмотря на буквальную формулировку в его системном промте: "Do NOT use the Bash to run commands when a relevant dedicated tool is provided" - я регулярно вижу, как модель скатывается к sed, awk, echo >, cat <<EOF и разным самопальным python-скриптам, когда внезапно нарывается на проблемы со вставкой своих патчей или вопросы с кодировками/переносами строк. Это очень раздражает ещё и потому, что клод код тогда требует явного подтверждения действия от пользователя. А с его однопотончной хук моделью это означает, что и другие агенты в это время ждут в очереди, что бы продолжить работу. Из-за этого невозможно отойти от монитора даже на пару минут. Один запутавшийся агент блокирует всех остальных.
Согласен, та же история - по логам постоянно юзает греп, ни разу не видел чтобы лез в анализ скомпилированного/промежуточного кода, всегда грепает. Мне понравилось, что сделал автор статьи, но у себя со Swift не смог повторить - очень сложно вытащить нужную информацию из SourceKit + нужно всегда синхронизировать/актуализировать индексацию при каждом запросе, хотел глянуть SLP так там вообще мрак самому всё писать и разбираться. Пет проект небольшой, пока и грепа хватает, но для большого видимо нужно прикручивать что-то помощнее что ниже писали про Serema MCP.
Serena mcp
Плюсанул. Это движение в правильном направлении, особенно, когда речь идет про полную автономность агентов.
Но для парной работы в специализированных средах -- и, особенно, когда вокруг все LLM-вендоры борются с тем, что бы их подписку не использовали в "самопальных" решениях и конкурентах (Opencode, OpenClaw и т.д.), когда уже начата открытая война с создатеями альтернативных агентных сред (зачастую гораздо более качественных, чем тот же Антигравити или Клод Код) -- не получится придумать ничего более естественного, чем CLI-шлюз к процессу твоей программы.
И дело ещё в cвободе, неохота оказаться в ситуации, как с ремонтом тракторов John Deere/заправкой картриджей HP -- когда ты, купив вещь, становишься рабом её дилера. И не можешь там даже лампочку поменять, без риска потери гарантии.
Спасибо за отзыв. LSP (или любой другой отдельный вычислительный процесс на стороне) был отброшен на ранней стадии — он не подходил под задачу. Мне нужно было вытаскивать информацию из процесса именно моей IDE. Нужны были именно её маркеры компиляции, её чекстайл, её тест-лаунчер и так далее. Отдельный Language Server — это отдельный индекс, отдельный build state, и он неизбежно рассинхронизируется с тем, что вы видите в IDE.
LSP — слишком низкоуровневая вещь, заточенная под редактор. Это протокол не для людей и не для агентов. textDocument/references с позиционными координатами в JSON-RPC — попробуйте это отдебажить руками. Даже если вы его как-то подключите — не факт, что ваша модель захочет этим пользоваться и не соскочит на свои фолбэки после первой же неудачи. Кто хоть немного поработал с кодинг-агентами — тот сразу поймёт, о чём речь. Модель нужно ещё убедить, что данный инструмент лучше и полезнее, чем то, на чём её тренировали. Агент обучен на grep/find, он к ним тянется рефлекторно. CLI с понятными командами (jdt refs, jdt err) имеет куда больше шансов быть подхваченным моделью, чем LSP JSON-RPC.
OpenCode для Java скачивает сервер от Eclipse и делает вызовы к нему. Без дополнительных запросов сам видит ошибки компиляции и исправляет их. Открытый Eclipse подтягивает обновившиеся файлы.
Автору статьи не нравится два экземпляра эклипса. Но авторы OpenCode в интервью сказали, что с переиспользованием уже установленного на машине LS есть проблемы.
Интересный кейс. Как специалист по ИБ, сразу задумываюсь о поверхности атаки при такой глубокой интеграции агента с IDE через внешние API. Если агент получает доступ к управлению "извне", это создает дополнительные риски внедрения вредоносного кода через промпты или компрометацию самого канала управления. Кто-нибудь уже задумывался о песочницах для таких агентов внутри IDE?
https://code.claude.com/docs/en/discover-plugins
Есть же плагин jdtls-lsp
Разве его недостаточно?
jdtls-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 ждать починки можно долго — проще сделать самому.
jdt внутри Explore субагента был бы идеальной связкой. Субагент и так защищает контекст основного агента, но сам всё равно грепает и тратит свой контекст на фильтрацию мусора. С jdt субагент получает 8 точных результатов сразу и возвращает основному агенту сухой остаток
Есть ещё неочевидный, ускользающий от внимания большинства момент про стоимость. Каждый tool call агента отправляет в API весь накопленный контекст -- все предыдущие запросы и ответы. Первый вызов -- 3k токенов, десятый -- уже 30k, двадцать пятый -- 65k. Это арифметическая прогрессия, сумма растёт квадратично от числа итераций.
Prompt caching снижает стоимость пересчёта, но за передачу кэшированных токенов всё равно нужно платить. Квадратичность остаётся. O(n²) живёт в протоколе, это следствие stateless HTTP-API и накопления контекста. Чем больше итераций нужно инструменту -- тем дороже каждый следующий шаг.
Забить итерациями до отсечки окно 200к Opus-a обходится примерно в 30 у.е., а сделать то же самое в 1M окне -- это уже 700 у.е.. Разница по бюджету ×23, а не ×5. Просто сейчас вендоры активно субсидируют расходы пользователей. Но эта щедрость не вечна и не бесконечна.
Доброго дня, я не профессиональный программист но тоже хотел бы сэкономить токены на вайбкодинге пет проектах.
Облачные IDE вроде Google Antigravity избавлены от такой проблемы?
И какие есть ещё более оптимизированные инструменты без сложных настроек? Заранее благодарю!
Из похожего есть https://github.com/defendend/Claude-ast-index-search
Нашел, наконец, время посмотреть, что же там под капотом. Если коротко: то Rust CLI + tree-sitter (варианты) Rust библиотек + SQLite FTS5 для индекса. В качестве основы для автономной работы (например, для экономной проверки пулреквестов) -- это вполне себе интересный вариант. На текущий момент java референсы пока парсятся регекспами, для котлина -- более умный парсер. Для парной работы с human-ом все же лучше настраивать тесную связь именно его любимым редактором.
В личные сообщения мне скинули отзыв, что по аналогии смогли за один час сделать CLI-версию для WebStorm -- доку писал gemini 3.1 pro, реализовывал gemini 3 flash. Если нужны подробности -- дайте знать.
@Kaluchi я там пару багов добавил - https://github.com/kaluchi/jdtbridge/issues
спасибо а почему не целиком на java - что помешало без node.js обойтись ? без ноды было бы веселее, было бы вообще годно
Если честно, даже не задумывался.. Мне все это надо было потом всё равно через claudecode/opencode использовать (т.е. транзитивно node рантайм у всех вайбкодеров уже есть рабочий). Мне хотелось побыстрее получить MVP, не ввязываясь в установку и поиски java (эклипс со своей встроенной идёт, а в системе java может и не быть отдельно). Да и по личному опыту, лучше всего у Opus-а получается код к node.js. Плюс этот код не страдает болезнями кодировок и прочими атавизами из древности. Opus уже мне не один десяток скриптов и тысячи тестов написал (хотя я и ни разу не js-программист).-- в 90% пишет верно и с первого раза все работает и зеленое.
Хотелось бы такую же для golang
Статья хорошая на самом деле, но вот месяц назад познакомился уже с российскии AI-IDE Kodik . Сам решает через VS Code индексацию плюс агенты с маршрутизацией моделей. Не grep, а нормальный ti/refs для агентского кодинга
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IDE понимает ваш код. AI-агент — нет. Это можно исправить