Привет, Хабр.

Сейчас почти каждый AI-кодинг-агент подключает LSP — Language Server Protocol. Это тот самый протокол, по которому редактор общается с языковым сервером: go-to-definition, find usages, hover с типом, диагностика. На этом обычно и пишут: «агент понимает код семантически».

Но мы в Veai делаем агента для JetBrains IDE, и нас периодически спрашивают: а зачем вообще нужен IDE, если LSP уже всё умеет? Хороший вопрос. LSP и правда решает много задач, но он проектировался для редактора, а не для агента. Подсветить ошибку, показать тип под курсором, найти ссылки — для этого LSP достаточно. А вот поменять Spring-бин в enterprise-проекте и не сломать сборку — тут нужно чуть больше.

Под катом разберём, что именно LSP даёт агенту, где этого перестаёт хватать и что поверх той же модели проекта предлагает JetBrains Platform. Спойлер: сравнивать LSP и PSI один в один бессмысленно — LSP это протокол, PSI это модель. Речь пойдёт о LSP vs весь стек IDE.

Когда подключаешь ИИ-агента к новому репозиторию, первые полчаса уходят не на код, а на объяснения. Какой стек, какие соглашения в команде, чем отлаживаемся, где лежат тесты, что нельзя трогать. Агент всего этого не знает – он стартует «универсальным» и собирает контекст по кусочкам, твоими руками, в каждом новом чате заново.

В Veai 5.13 мы попробовали закрыть именно эту боль. Главная фича релиза — онбординг агента в проект: при первом запуске агент сам проходит короткий диалог и за минуту настраивает себя под вашу кодовую базу – создаёт правила, подключает навыки и внешние инструменты. Дальше он с первого сообщения говорит на языке вашего проекта.

Разберёмся, как это устроено, в какие файлы всё сохраняется. А ещё пройдёмся по остальным изменениям релиза: генерация тестов в WebStorm и PyCharm, доступ к файлам за пределами проекта и хоткей для переключения между редактором и чатом.

Когда работаешь с AI-агентом в большом проекте каждый день, накапливаются две усталости. 

Первая – объяснять одно и то же. В каждом новом чате заново рассказываешь, какой у вас стек, каким тестовым фреймворком пользуетесь, чем отлаживаете, что после правки нужно прогнать тесты. 

Вторая – платить сильной моделью за задачи, которым хватило бы простой: поиск файла или чтение пары классов тянет ту же дорогую модель, что и сложный рефакторинг.

В Veai 5.14 мы взялись за обе. Появился Memory Bank – агент запоминает факты о проекте между чатами. И профили маршрутизации моделей – субагенты работают на разных моделях под разные задачи. Плюс окно результатов ревью, проектные MCP-серверы и несколько изменений в интерфейсе. Разберём по порядку.

Главная ценность релиза — разработчик начинает с рабочей задачи, а не с выбора режима.

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

Для этого в Veai 5.12 появился General Agent. Он принимает задачу в том виде, в каком разработчик обычно ее формулирует: неидеально, с сомнениями и неполным пониманием пути. Агент сам подбирает нужные действия и отдает результат, который уже можно проверить.

Попробовать Veai 5.12 · Что входит в релиз

В этом релизе мы собрали изменения, которые закрывают весь путь работы с агентом: от первого сообщения в чат до проверки результата.

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

Модель может хорошо писать текст, аккуратно рассуждать о коде и уверенно предлагать правки. Но если все, что она видит, это grep, несколько похожих файлов, команда в терминале и длинный лог, то ее выводы строятся на шумном сигнале. Иногда этого хватает. На небольшом проекте, с сильной моделью и простой задачей, агент действительно может быстро помочь. Но! В enterprise-коде ситуация другая. Важны конкретная версия зависимости, выбранная run configuration, classpath, SDK, профиль, состояние объекта в рантайме, IDE warnings, usages, inspections, trace уязвимости, важны факты, без которых агент начинает угадывать.

Разберем на последних релизах Veai 5.8-5.11 рабочий цикл разработчика в любимой IDE.

Почему классический разбор SAST-находок — это боль

Сценарий, знакомый многим разработчикам в крупных компаниях: перед релизом ИБ-отдел присылает выгрузку из корпоративного сканера. В этом PDF-файле на сотни страниц собраны тонны находок. Большая часть из них снабжена метками вроде Critical. И вот, вместо скроллинга ленты подготовки релиза разработчик сталкивается с трудоемким процессом анализа:

Открыть указанный в отчете файл

Обнаружить там какую-нибудь generic-функцию, которая принимает строку и склеивает SQL-запрос

Раскопать через цепочки вызовов, откуда вообще берутся данные. Приходят ли они напрямую от пользователя из REST-контроллера, контролируются ли они внутренней конфигурацией, или это вообще внутренний технический ID, который заведомо безопасен?

Разобраться, была ли где-то по дороге валидация или экранирование

Решить, действительно ли это эксплуатируемая уязвимость, или ее появление в отчете вызвано ложным срабатыванием из-за неполноты контекста анализатора.

Это конспект вебинара. Спикер — Даниил Степанов, разработчик‑исследователь Veai, преподаватель ИТМО, ранее работал в JetBrains и Huawei.

AI уже пишет заметную часть промышленного кода, а процессы качества у многих команд остались такими, будто код всё ещё пишет только человек и в прежнем объёме.

Если коротко: проблема чаще всего не в том, что «модель тупая». Проблема в том, что вокруг агента нет инженерного контура: спецификации, ограничений, независимых тестов, security‑checks, ревью‑пайплайна и артефактов, которым можно верить.

 Архитектура «оркестратор + сабагенты» на одном экране: ведущий агент держит план и раздаёт подзадачи изолированным сабагентам.

Один AI-агент в чате – это удобно, пока задача помещается в контекст. Как только она начинает разъезжаться по 30 файлам, четырём ролям и циклу «исследуй – реализуй – отревьюй – поправь», единый чат превращается в свалку: модель путает, какой шаг где, тащит решения из первой задачи в третью и стабильно проседает по качеству начиная с заполнения окна примерно наполовину. Схема «оркестратор + сабагенты» – это инженерный ответ на проблему: один ведущий агент держит план и раздаёт подзадачи изолированным сабагентам с пустым контекстом.

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

Когда AI-агенту дают только stack trace и текст файла с упавшим тестом, он часто чинит симптом, а не причину. Тест зеленеет, баг переезжает в master, через неделю всплывает в другом месте. На простых багах это незаметно, на нетривиальных — становится правилом.

В этой статье — что меняется, если вместо stack trace дать агенту сжатый трейс выполнения, собранный на стороне IDE. Три бага из реального кода, эвристики сжатия трейса, склейка многопоточных вызовов по timestamp и цифры на датасете BugSwarm Pro для DeepSeek V3.2 и проприетарных LLM.

Статья пригодится, если вы:

Главное в Veai 5.10 – скиллы теперь подхватываются из dot-директорий других ассистентов. В чат добавили быструю документацию по ссылкам на код.

Запуск и получение конфигураций в Rider

До Veai 5.10 в C#/.NET-проекте нужно было просить агента прогнать тесты в модуле или собрать проект. Агент шёл в терминал и пытался угадать команду: какой dotnet, какой TFM, какой фильтр и какой путь к csproj. На монорепо с несколькими SDK и global.json это регулярно заканчивалось exit code 1 и попыткой починить рабочий код.

Цепочка короткая: сначала был просто автокомплит, потом появились чаты, в которые надо было руками копировать код туда-обратно (и человек выступал прокси между моделью и проектом — «много ручной работы, контекст рвётся»). Потом пришли агенты, которые живут прямо в проекте, читают и правят файлы, запускают команды. Сверху — агентские системы, которые координируют нескольких агентов и решают проблему перегрузки одного контекста.

Где живёт агент: три класса инструментов

Как проверить, что ИИ-агент в IDE работает, если на одинаковые запросы LLM отвечает по-разному? Ответы модели недетерминированы, а интерфейс и бизнес-логика вполне детерминированы, и их нужно тестировать отдельно.

Мы делаем ИИ-агента, встраиваемого в JetBrains IDE. В статье расскажу, как мы выстроили UI-автоматизацию плагина так, чтобы тесты ловили регрессии в интерфейсе, бизнес-логике и при этом не «моргали» из-за нестабильности LLM.

В Veai мы регулярно тестируем и сравниваем модели, которые доступны у нас в плагине. Каждая модель, которую мы добавляем проходит через наш собственный бенчмарк, прежде чем попасть в продакшн. Недавно тестированию подверглись GLM 5.1 и DeepSeek V3.2. Делимся результатами.

Три минуты на планирование, десять на исполнение. Да, в масштабах человека это быстро, но уже хочется еще быстрее!

Судя по всему, я не одна такая. Посмотрите на провайдеров, которые за доплату дают ответы в два-три раза быстрее. Спрос есть, значит желание такое имеется не только у меня.

Но платить за скорость — не единственный выход.

В конце прошлого года Cursor выпустил Debug Mode — режим, в котором агент может собирать логи из рантайма, чтобы лучше понимать причины багов. Судя по реакции на Reddit, идею приняли с интересом.

Но что, если пойти более прямым путём? Дать агенту «руки», чтобы он отлаживался так же, как это делает разработчик: ставил брейкпоинты, ходил по ним, выполнял evaluate expression? Этим вопросом недавно задались исследователи из Microsoft Research и сделали экспериментальный фреймворк Debug2Fix. Субагент, оснащённый инструментами для взаимодействия с отладчиком, разбирался с багами из датасетов GitBug-Java и SWE-Bench-Live на 20% лучше, чем обычный агент без таких инструментов.

Если агент уже интегрирован с IDE, естественно дать ему доступ к полноценному дебаггеру, когда он так близко. Тем более что этим занимаются даже в Microsoft. Поэтому в недавнем релизе своего ассистента для IntelliJ мы добавили Debug Agent, позволяющий агенту взаимодействовать с дебаггером в среде разработки.

Сегодня попробуем починить реальный баг с помощью агента с инструментами дебаггера в IDE и Cursor в Debug Mode и проверим, действительно ли ИИ нужен полный доступ к отладчику или достаточно и хорошего логгирования.

Способности LLM писать код растут очень быстро. А вот инженерные практики вокруг них – заметно медленнее. Поэтому на рынке одновременно существуют две реальности.

В одной AI действительно ускоряет разработку: команда быстрее выполняет задачи, реже тонет в рутине и, что немаловажно, не проигрывает в качестве. В другой – тот же самый AI плодит тонны кода, который потом приходится дольше ревьюить, переписывать и отлаживать.

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

Дебаг, запуск проекта и рефакторинг. Все мы хорошо знакомы с этими фичами IDE и пользуемся ими практически каждый день. Но передовые ИИ-агенты для кодинга почему-то абсолютно ничего не знали про эту “базу” до релиза Veai 5.8 🙂 (ИИ-агент к JetBrains IDEs для написания кода, тестирования и отладки с доступом к топовым LLM и всем внутренним инструментам IDE).

Помимо глубокой интеграции агента с вашей любимой IDE, мы завезли ещё парочку улучшений и изменили подход к тарификации. Но обо всём по порядку.

Все современные языковые модели иногда ведут себя так, будто у них есть эмоции: они «рады помочь», «извиняются» за ошибки и словно «нервничают», когда задача не даётся. Новое исследование Anthropic показывает, что это не просто стиль ответа — внутри моделей действительно возникают функциональные представления эмоций, которые влияют на поведение: например, «отчаяние» повышает шанс выбрать неэтичный или «костыльный» путь решения задачи. То, как обучаются модели, подталкивает их играть роль персонажа с человеческими чертами и формировать богатые внутренние представления абстрактных концептов, включая эмоциональные.

Возникает практический вопрос: если у модели есть такие функциональные «эмоции», как с этим работать в промышленной разработке? Как сделать так, чтобы агент в сложной ситуации не «паниковал» и не уходил в небезопасные или нестабильные решения, а действовал предсказуемо и по правилам? Здесь важен не только выбор базовой модели, но и то, в какой среде она работает и какими инструментами пользуется.

Возьмём Veai и посмотрим на это через призму архитектуры. В основе Veai лежит идея максимально использовать инструменты IDE: Veai относится к Claude Code примерно так же, как разработчик с IDE относится к разработчику, сидящему только в терминале.

Релиз Veai 5.7 (ИИ-агент к JetBrains IDEs для написания кода, тестирования и отладки с доступом к топовым LLM и всем внутренним инструментам IDE) собрал в себе много исправлений неочевидного UX, с которым вы сталкивались ежедневного. Меньше ручных переключений, меньше ожидания между шагами, меньше повторов при сбоях.

Работа с агентом обычно прерывается мелкими операциями: написать сообщение коммита, скопировать кусок ответа, прикрепить скриншот. В релизе Veai 5.6 (ИИ-агент к JetBrains IDEs для написания кода, тестирования и отладки с доступом к топовым LLM и всем внутренним инструментам IDE) мы убрали часть этой рутины. Добавили генерацию коммитов из diff, быстрые действия для текста ответа, явный технический контекст запроса, ручной вызов Skills и более простой способ прикреплять изображения.