Нашел, наконец, время посмотреть, что же там под капотом. Если коротко: то Rust CLI + tree-sitter (варианты) Rust библиотек + SQLite FTS5 для индекса. В качестве основы для автономной работы (например, для экономной проверки пулреквестов) -- это вполне себе интересный вариант. На текущий момент java референсы пока парсятся регекспами, для котлина -- более умный парсер. Для парной работы с human-ом все же лучше настраивать тесную связь именно его любимым редактором.
В личные сообщения мне скинули отзыв, что по аналогии смогли за один час сделать CLI-версию для WebStorm -- доку писал gemini 3.1 pro, реализовывал gemini 3 flash. Если нужны подробности -- дайте знать.
Если честно, даже не задумывался.. Мне все это надо было потом всё равно через claudecode/opencode использовать (т.е. транзитивно node рантайм у всех вайбкодеров уже есть рабочий). Мне хотелось побыстрее получить MVP, не ввязываясь в установку и поиски java (эклипс со своей встроенной идёт, а в системе java может и не быть отдельно). Да и по личному опыту, лучше всего у Opus-а получается код к node.js. Плюс этот код не страдает болезнями кодировок и прочими атавизами из древности. Opus уже мне не один десяток скриптов и тысячи тестов написал (хотя я и ни разу не js-программист).-- в 90% пишет верно и с первого раза все работает и зеленое.
Спасибо вам огромное! Рад, что вы оценили проект и даже внесли свой личный вклад в него. И про тесты не забыли) Это здорово! Смержил. Плюсик вам в карму.
Есть ещё неочевидный, ускользающий от внимания большинства момент про стоимость. Каждый tool call агента отправляет в API весь накопленный контекст -- все предыдущие запросы и ответы. Первый вызов -- 3k токенов, десятый -- уже 30k, двадцать пятый -- 65k. Это арифметическая прогрессия, сумма растёт квадратично от числа итераций.
Prompt caching снижает стоимость пересчёта, но за передачу кэшированных токенов всё равно нужно платить. Квадратичность остаётся. O(n²) живёт в протоколе, это следствие stateless HTTP-API и накопления контекста. Чем больше итераций нужно инструменту -- тем дороже каждый следующий шаг.
Забить итерациями до отсечки окно 200к Opus-a обходится примерно в 30 у.е., а сделать то же самое в 1M окне -- это уже 700 у.е.. Разница по бюджету ×23, а не ×5. Просто сейчас вендоры активно субсидируют расходы пользователей. Но эта щедрость не вечна и не бесконечна.
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 ждать починки можно долго — проще сделать самому.
Лимитов по токенам хватило на задачу? Я так понимаю, там тариф 16 евро в месяц? А как делали? Всё в их облаке или есть какие-то CLI для неё? Первый раз про Figma Make слышу.. Простите, за нубские вопросы, просто раз это туториал, то может они уместны будут здесь.
В Claude Code несмотря на буквальную формулировку в его системном промте: "Do NOT use the Bash to run commands when a relevant dedicated tool is provided" - я регулярно вижу, как модель скатывается к sed, awk, echo >, cat <<EOF и разным самопальным python-скриптам, когда внезапно нарывается на проблемы со вставкой своих патчей или вопросы с кодировками/переносами строк. Это очень раздражает ещё и потому, что клод код тогда требует явного подтверждения действия от пользователя. А с его однопотончной хук моделью это означает, что и другие агенты в это время ждут в очереди, что бы продолжить работу. Из-за этого невозможно отойти от монитора даже на пару минут. Один запутавшийся агент блокирует всех остальных.
Плюсанул. Это движение в правильном направлении, особенно, когда речь идет про полную автономность агентов.
Но для парной работы в специализированных средах -- и, особенно, когда вокруг все LLM-вендоры борются с тем, что бы их подписку не использовали в "самопальных" решениях и конкурентах (Opencode, OpenClaw и т.д.), когда уже начата открытая война с создатеями альтернативных агентных сред (зачастую гораздо более качественных, чем тот же Антигравити или Клод Код) -- не получится придумать ничего более естественного, чем CLI-шлюз к процессу твоей программы.
И дело ещё в cвободе, неохота оказаться в ситуации, как с ремонтом тракторов John Deere/заправкой картриджей HP -- когда ты, купив вещь, становишься рабом её дилера. И не можешь там даже лампочку поменять, без риска потери гарантии.
Десятки всяких песочниц уже есть. Начиная с docker sandobx и gVisor (на которых облачный клод код работает) и заканчивая всякими менее распространенными вариантами.
Спасибо за отзыв. LSP (или любой другой отдельный вычислительный процесс на стороне) был отброшен на ранней стадии — он не подходил под задачу. Мне нужно было вытаскивать информацию из процесса именно моей IDE. Нужны были именно её маркеры компиляции, её чекстайл, её тест-лаунчер и так далее. Отдельный Language Server — это отдельный индекс, отдельный build state, и он неизбежно рассинхронизируется с тем, что вы видите в IDE.
LSP — слишком низкоуровневая вещь, заточенная под редактор. Это протокол не для людей и не для агентов. textDocument/references с позиционными координатами в JSON-RPC — попробуйте это отдебажить руками. Даже если вы его как-то подключите — не факт, что ваша модель захочет этим пользоваться и не соскочит на свои фолбэки после первой же неудачи. Кто хоть немного поработал с кодинг-агентами — тот сразу поймёт, о чём речь. Модель нужно ещё убедить, что данный инструмент лучше и полезнее, чем то, на чём её тренировали. Агент обучен на grep/find, он к ним тянется рефлекторно. CLI с понятными командами (jdt refs, jdt err) имеет куда больше шансов быть подхваченным моделью, чем LSP JSON-RPC.
Кажется, что в Anthropic всем навязали KPI на медиаприсутствие. Вместо того, что бы фиксить 5500+ багов в своем Claide Code (на самом деле их гораздо больше - просто они закрываются автоматически) -- их контора фокусируются на cоздании разных хелло-вордных MVP, лишь имитирующих развитие и дающих повод о себе напомнить.
Расскажите, зачем вообще нужен RAG в 2026 году? Получать ответ за одну итерацию инференса? Добивать промт от юзера релевантным мусором? Я просто хочу разобраться.. как это ПРАВИЛЬНО готовить? Поверх серч резалтов выполнять саммаризацию, как это делает гугл? Но компилятору требуется точный ответ, а не отписка... Какой профит с этого? Наличие полученной по неизвестным для модели правилам RAG-выдачи в контексте как-то побуждает её серьезнее относиться к задаче, она будет меньше сочинять и выдумывать? Где эта ниша, где RAG -- непоколебимый король?
Да, такой подход работает для любого софта, который позволяет собрать себя из исходников или расширить плагинами. Если у инструмента есть API — внутренний, плагинный, какой угодно — этого достаточно, чтобы вытянуть из него нити управления наружу и сделать доступным для агента. По сути, это универсальный рецепт пульта дистанционного управления для чего угодно.
Да, с обычным CLI не нужно сочинять и расписывать все эти фильтрующие/лимитирующие параметры для каждой команды с теоретически большим выводом -- агенты обычно сами подстраховывают tail/head-ами. С CLI не нужен MCP Inspector и т.п. отладочные инструменты. CLI есть у докера, авс, сентри, гитхаба и т.д. --- и агенты с ними прекрасно ладят. Просто MCP создан для немного для другого уровня интеграции (когда у агента нет баша), а когда терминал есть -- то CLI-утилита/скрипт это более подходящий способ расширения функционала агента: нет проблем с раздутым описанием инструментов -- не рассказал агенту - он и не знает ничего, а когда задача требует навыка -- то просто используешь скилл, в котором описано, как пользоваться твоими CLI/скриптами. Все просто.
Буквально вчера, 19 февраля 2026, Anthropic официально обновила документацию и окончательно закрыла лазейки.
Что официально разрешено с подпиской Pro/Max (без API-ключа):
Claude.ai — веб, десктоп, мобилка. Без вопросов.
Claude Code (официальный CLI) — единственный инструмент разработки, который Anthropic официально включила в подписку. Это всё. Больше ничего официального нет.
Anthropic обновила документацию, уточнив, что использование OAuth-токенов с любыми сторонними инструментами нарушает условия использования. OAuth-токены из планов Free, Pro и Max предназначены исключительно для Claude Code и Claude.ai — использование этих токенов в любых других продуктах, инструментах или сервисах, включая Agent SDK, является нарушением условий.
Что раньше работало, а теперь заблокировано: Под удар попали: OpenCode, Cline (через OAuth), RooCode, Cursor (когда использовался как прокси для подписки). Cline и RooCode, которые использовали подписочные кредиты Claude, тоже сломались.
Этому товарищу бы лучше за своей кривой терминальной поделкой следить (6200+ issues на Github), а не по интервью ходить.
У Claude Code до сих пор все внутренние и внешние хуки живут в одном треде с UI event loop. Из-за этого всё хозяйство безбожно тормозит и клинит при любом параллельном запуске или объемном выводе, засыпая консоль react-эксепшенами из субагентов и выжирая 100% CPU на ровном месте.
Про отсутствие контроля над субагентами я вообще молчу: те часто игнорируют инструкции, залезают куда попало, там застревают в хуках (особенно Sonnet со своей любовью к баш-пайплайнам) -- и пока пользователь не нажмет "No", все остальные агенты в это время стоят в очереди. А ещё бесконтрольная компактификация. Она затирает историю и для агента, и для человека! Она трет контекст как захочет, включая и то, что было положено программистом в Claude.md. В итоге проще вообще не доводить диалог до компактификации, и вести разработку в своих собственных roadmap-файлах и своими ссылками на правила бутстрапить контекст.
Невозможно троттлить скорость работы субагентов, ставить на паузу или возобновлять работу. Некоторые вещи до сих пор проще и экономнее в старом Claude Desktop c голыми mcp сделать -- чем пытаться воевать с Claude Code. Их контекстые rules до сих не работают и затягиваются в контекст сразу все (и так же потом игнорируются компактификацией). Две разных системы хуков для главного агента и для субагентов. Субагенты живут в одной сессии с главным агентом. Без серьезных плясок с бубном в хуках невозможно отличить какой именно субагент вызывает сейчас инструмент, какой какой тип, айди у суб-агента.
Все это в совокупности убивает весь UX Claude Code. И если бы не принудительная привязка подписки к нему -- большинство бы уже давно перешло в другие агентные среды.
Попросите у Opus - он вам сделает аналог за 1 час)
Нашел, наконец, время посмотреть, что же там под капотом. Если коротко: то Rust CLI + tree-sitter (варианты) Rust библиотек + SQLite FTS5 для индекса. В качестве основы для автономной работы (например, для экономной проверки пулреквестов) -- это вполне себе интересный вариант. На текущий момент java референсы пока парсятся регекспами, для котлина -- более умный парсер. Для парной работы с human-ом все же лучше настраивать тесную связь именно его любимым редактором.
В личные сообщения мне скинули отзыв, что по аналогии смогли за один час сделать CLI-версию для WebStorm -- доку писал gemini 3.1 pro, реализовывал gemini 3 flash. Если нужны подробности -- дайте знать.
Если честно, даже не задумывался.. Мне все это надо было потом всё равно через claudecode/opencode использовать (т.е. транзитивно node рантайм у всех вайбкодеров уже есть рабочий). Мне хотелось побыстрее получить MVP, не ввязываясь в установку и поиски java (эклипс со своей встроенной идёт, а в системе java может и не быть отдельно). Да и по личному опыту, лучше всего у Opus-а получается код к node.js. Плюс этот код не страдает болезнями кодировок и прочими атавизами из древности. Opus уже мне не один десяток скриптов и тысячи тестов написал (хотя я и ни разу не js-программист).-- в 90% пишет верно и с первого раза все работает и зеленое.
Спасибо вам огромное! Рад, что вы оценили проект и даже внесли свой личный вклад в него. И про тесты не забыли) Это здорово! Смержил. Плюсик вам в карму.
Главная проблема с переиспользованием эклписа -- это его зоопарк версий. Выбор разработчиков понятен. Но ваша IDE это больше, чем Language Server
Есть ещё неочевидный, ускользающий от внимания большинства момент про стоимость. Каждый tool call агента отправляет в API весь накопленный контекст -- все предыдущие запросы и ответы. Первый вызов -- 3k токенов, десятый -- уже 30k, двадцать пятый -- 65k. Это арифметическая прогрессия, сумма растёт квадратично от числа итераций.
Prompt caching снижает стоимость пересчёта, но за передачу кэшированных токенов всё равно нужно платить. Квадратичность остаётся. O(n²) живёт в протоколе, это следствие stateless HTTP-API и накопления контекста. Чем больше итераций нужно инструменту -- тем дороже каждый следующий шаг.
Забить итерациями до отсечки окно 200к Opus-a обходится примерно в 30 у.е., а сделать то же самое в 1M окне -- это уже 700 у.е.. Разница по бюджету ×23, а не ×5. Просто сейчас вендоры активно субсидируют расходы пользователей. Но эта щедрость не вечна и не бесконечна.
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 ждать починки можно долго — проще сделать самому.
Лимитов по токенам хватило на задачу? Я так понимаю, там тариф 16 евро в месяц? А как делали? Всё в их облаке или есть какие-то CLI для неё? Первый раз про Figma Make слышу.. Простите, за нубские вопросы, просто раз это туториал, то может они уместны будут здесь.
В Claude Code несмотря на буквальную формулировку в его системном промте: "Do NOT use the Bash to run commands when a relevant dedicated tool is provided" - я регулярно вижу, как модель скатывается к sed, awk, echo >, cat <<EOF и разным самопальным python-скриптам, когда внезапно нарывается на проблемы со вставкой своих патчей или вопросы с кодировками/переносами строк. Это очень раздражает ещё и потому, что клод код тогда требует явного подтверждения действия от пользователя. А с его однопотончной хук моделью это означает, что и другие агенты в это время ждут в очереди, что бы продолжить работу. Из-за этого невозможно отойти от монитора даже на пару минут. Один запутавшийся агент блокирует всех остальных.
Плюсанул. Это движение в правильном направлении, особенно, когда речь идет про полную автономность агентов.
Но для парной работы в специализированных средах -- и, особенно, когда вокруг все LLM-вендоры борются с тем, что бы их подписку не использовали в "самопальных" решениях и конкурентах (Opencode, OpenClaw и т.д.), когда уже начата открытая война с создатеями альтернативных агентных сред (зачастую гораздо более качественных, чем тот же Антигравити или Клод Код) -- не получится придумать ничего более естественного, чем CLI-шлюз к процессу твоей программы.
И дело ещё в cвободе, неохота оказаться в ситуации, как с ремонтом тракторов John Deere/заправкой картриджей HP -- когда ты, купив вещь, становишься рабом её дилера. И не можешь там даже лампочку поменять, без риска потери гарантии.
Десятки всяких песочниц уже есть. Начиная с docker sandobx и gVisor (на которых облачный клод код работает) и заканчивая всякими менее распространенными вариантами.
Спасибо за отзыв. LSP (или любой другой отдельный вычислительный процесс на стороне) был отброшен на ранней стадии — он не подходил под задачу. Мне нужно было вытаскивать информацию из процесса именно моей IDE. Нужны были именно её маркеры компиляции, её чекстайл, её тест-лаунчер и так далее. Отдельный Language Server — это отдельный индекс, отдельный build state, и он неизбежно рассинхронизируется с тем, что вы видите в IDE.
LSP — слишком низкоуровневая вещь, заточенная под редактор. Это протокол не для людей и не для агентов. textDocument/references с позиционными координатами в JSON-RPC — попробуйте это отдебажить руками. Даже если вы его как-то подключите — не факт, что ваша модель захочет этим пользоваться и не соскочит на свои фолбэки после первой же неудачи. Кто хоть немного поработал с кодинг-агентами — тот сразу поймёт, о чём речь. Модель нужно ещё убедить, что данный инструмент лучше и полезнее, чем то, на чём её тренировали. Агент обучен на grep/find, он к ним тянется рефлекторно. CLI с понятными командами (jdt refs, jdt err) имеет куда больше шансов быть подхваченным моделью, чем LSP JSON-RPC.
Кажется, что в Anthropic всем навязали KPI на медиаприсутствие. Вместо того, что бы фиксить 5500+ багов в своем Claide Code (на самом деле их гораздо больше - просто они закрываются автоматически) -- их контора фокусируются на cоздании разных хелло-вордных MVP, лишь имитирующих развитие и дающих повод о себе напомнить.
Расскажите, зачем вообще нужен RAG в 2026 году? Получать ответ за одну итерацию инференса? Добивать промт от юзера релевантным мусором? Я просто хочу разобраться.. как это ПРАВИЛЬНО готовить? Поверх серч резалтов выполнять саммаризацию, как это делает гугл? Но компилятору требуется точный ответ, а не отписка... Какой профит с этого? Наличие полученной по неизвестным для модели правилам RAG-выдачи в контексте как-то побуждает её серьезнее относиться к задаче, она будет меньше сочинять и выдумывать? Где эта ниша, где RAG -- непоколебимый король?
Да, такой подход работает для любого софта, который позволяет собрать себя из исходников или расширить плагинами. Если у инструмента есть API — внутренний, плагинный, какой угодно — этого достаточно, чтобы вытянуть из него нити управления наружу и сделать доступным для агента. По сути, это универсальный рецепт пульта дистанционного управления для чего угодно.
Да, с обычным CLI не нужно сочинять и расписывать все эти фильтрующие/лимитирующие параметры для каждой команды с теоретически большим выводом -- агенты обычно сами подстраховывают tail/head-ами. С CLI не нужен MCP Inspector и т.п. отладочные инструменты. CLI есть у докера, авс, сентри, гитхаба и т.д. --- и агенты с ними прекрасно ладят. Просто MCP создан для немного для другого уровня интеграции (когда у агента нет баша), а когда терминал есть -- то CLI-утилита/скрипт это более подходящий способ расширения функционала агента: нет проблем с раздутым описанием инструментов -- не рассказал агенту - он и не знает ничего, а когда задача требует навыка -- то просто используешь скилл, в котором описано, как пользоваться твоими CLI/скриптами. Все просто.
Буквально вчера, 19 февраля 2026, Anthropic официально обновила документацию и окончательно закрыла лазейки.
Что официально разрешено с подпиской Pro/Max (без API-ключа):
Claude.ai — веб, десктоп, мобилка. Без вопросов.
Claude Code (официальный CLI) — единственный инструмент разработки, который Anthropic официально включила в подписку. Это всё. Больше ничего официального нет.
Anthropic обновила документацию, уточнив, что использование OAuth-токенов с любыми сторонними инструментами нарушает условия использования. OAuth-токены из планов Free, Pro и Max предназначены исключительно для Claude Code и Claude.ai — использование этих токенов в любых других продуктах, инструментах или сервисах, включая Agent SDK, является нарушением условий.
Что раньше работало, а теперь заблокировано:
Под удар попали: OpenCode, Cline (через OAuth), RooCode, Cursor (когда использовался как прокси для подписки). Cline и RooCode, которые использовали подписочные кредиты Claude, тоже сломались.
Этому товарищу бы лучше за своей кривой терминальной поделкой следить (6200+ issues на Github), а не по интервью ходить.
У Claude Code до сих пор все внутренние и внешние хуки живут в одном треде с UI event loop. Из-за этого всё хозяйство безбожно тормозит и клинит при любом параллельном запуске или объемном выводе, засыпая консоль react-эксепшенами из субагентов и выжирая 100% CPU на ровном месте.
Про отсутствие контроля над субагентами я вообще молчу: те часто игнорируют инструкции, залезают куда попало, там застревают в хуках (особенно Sonnet со своей любовью к баш-пайплайнам) -- и пока пользователь не нажмет "No", все остальные агенты в это время стоят в очереди. А ещё бесконтрольная компактификация. Она затирает историю и для агента, и для человека! Она трет контекст как захочет, включая и то, что было положено программистом в Claude.md. В итоге проще вообще не доводить диалог до компактификации, и вести разработку в своих собственных roadmap-файлах и своими ссылками на правила бутстрапить контекст.
Невозможно троттлить скорость работы субагентов, ставить на паузу или возобновлять работу. Некоторые вещи до сих пор проще и экономнее в старом Claude Desktop c голыми mcp сделать -- чем пытаться воевать с Claude Code. Их контекстые rules до сих не работают и затягиваются в контекст сразу все (и так же потом игнорируются компактификацией). Две разных системы хуков для главного агента и для субагентов. Субагенты живут в одной сессии с главным агентом. Без серьезных плясок с бубном в хуках невозможно отличить какой именно субагент вызывает сейчас инструмент, какой какой тип, айди у суб-агента.
Все это в совокупности убивает весь UX Claude Code. И если бы не принудительная привязка подписки к нему -- большинство бы уже давно перешло в другие агентные среды.
accept interfaces, return concrete types
Откуда информация такая?