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

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

«В enterprise-коде так не работает. Там важны версия зависимости, выбранная run configuration, classpath, SDK, профиль запуска, состояние объекта в рантайме, IDE warnings, usages, inspections, trace уязвимости. Это не украшения поверх разработки. Это данные, без которых агент начинает угадывать.»

Наши релизы Veai 5.8-5.11 как раз об этом: агент стал ближе к обычному рабочему циклу разработчика в любимой IDE.

Что разберем:

• почему цикл «grep -> похожие файлы -> terminal -> длинный лог -> догадка» плохо держится на больших проектах;

• что меняется, когда агент запускает код через IDE;

• почему debugger часто лучше временных println;

• зачем агенту semantic Rename вместо текстовой замены;

• где Skills и субагенты помогают, а где съедают контекст;

• почему код подключенной зависимости надежнее документации из интернета;

• как SAST попадает в тот же рабочий цикл, где агент пишет и правит код.

Обычный цикл агента

Представьте AI-агента в Java-проекте. Ему дают задачу: «найди, почему тест падает, и исправь».

Чаще всего дальше происходит так:

1. агент читает дерево проекта;

2. ищет по ключевым словам;

3. открывает несколько похожих файлов;

4. запускает что-то вроде ./gradlew test;

5. получает большой лог;

6. пытается вытащить из него важное;

7. правит код;

8. повторяет все заново.

На каждом шаге можно ошибиться. Поиск нашел не тот класс. RAG поднял похожий, но бесполезный файл. Команда запустилась не с тем профилем. В логе сотни строк, а нужны пять. Модель делает правдоподобный вывод, но он стоит на обрывках.

Поэтому вопрос не в том, как агент рассуждает. Вопрос в том, какие данные он получает.

IDE уже знает структуру проекта, symbols, usages, run configurations, SDK, classpath, inspections, debugger, coverage и зависимости. В последних релизах Veai активнее использует именно этот слой.

Запуск через IDE, а не подбор команды

Начнем с обычной задачи. Агент изменил код. Теперь надо проверить результат.

В простом проекте можно написать:

./gradlew test

В рабочем проекте сразу появляются детали:

• нужна конкретная JDK;

• тест лежит в отдельном модуле;

• используется профиль окружения;

• рабочая директория не совпадает с корнем репозитория;

• часть переменных уже прописана в IDE-конфигурации;

• интеграционный тест запускается иначе, чем unit-тест.

Разработчик обычно не вбивает все это руками. Он сразу запускает нужную конфигурацию.

В Veai 5.8 агент научился работать с run configurations через IDE: смотреть доступные конфигурации и запускать нужную. В 5.11 эту логику расширили для других IDE.

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

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

Чтение кода: сначала карта файла

Файл на 150 строк можно прочитать целиком. Файл на 1000 строк уже опасен: модель тратит контекст на лишнее и может потерять нужный метод. JSON или YAML на несколько тысяч строк еще хуже.

IDE умеет показывать структуру файла: классы, методы, поля, позиции. Для агента это оглавление. Сначала он смотрит карту, потом читает нужный кусок.

Чем меньше лишнего попадает в контекст, тем меньше модель додумывает.

Зависимости: код в classpath надежнее примера из интернета

Enterprise-проект нельзя понять только по исходникам текущего репозитория.

Часть логики живет во внутренних библиотеках. Другая часть зависит от конкретной версии framework API. LLM часто знает похожий API, но не обязательно тот, который подключен в проекте.

Типичная ошибка выглядит так:

1. агент видит вызов client.parse(payload);

2. ищет документацию или похожие примеры;

3. находит API другой версии;

4. пишет код, который выглядит правильно;

5. в проекте этот код не работает или ломается в runtime.

Veai может через IDE открыть код подключенной зависимости или декомпилированный класс. Агент смотрит не пример из интернета, а версию, которая стоит в classpath проекта.

Для разработки это практичнее, чем пытаться "знать все". Агенту важнее уметь быстро добраться до правильного источника.

Ошибки во время редактирования

Обычный цикл исправления ошибки длинный:

1. агент меняет код;

2. запускает сборку;

3. получает лог;

4. ищет ошибку;

5. правит;

6. запускает снова.

Разработчик в IDE видит часть проблем раньше: подсветку, warnings, quick fixes, inspections. Если импорт не тот, тип не сходится или метод недоступен, это видно почти сразу.

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

Rename: sed не делает рефакторинг

Переименование кажется простой задачей: заменить имя класса, метода или поля.

В большом проекте это не текстовая операция. У символа есть usages, imports, overloads, getters/setters, тесты, иногда связанные имена. Глобальная замена может задеть лишнее. Ручная правка по grep может что-то пропустить.

В Veai 5.8 появился Rename через действия IDE. Агент может вызвать тот же semantic refactoring, который разработчик запускает через Shift+F6.

Разница простая: обычный агент видит совпадения строк, агент Veai работает с символом в проектной модели IDE.

Debug Mode вместо временных логов

Теперь runtime-баг.

Тест падает. По stack trace видно место, где все закончилось, но не видно, где состояние стало неправильным. Например, объект прошел через несколько сервисов, одно поле изменилось раньше ожидаемого, и в конце бизнес-логика выбрала не ту ветку.

Обычный агент часто вставляет временные логи:

System.out.println("user=" + user);
System.out.println("state=" + state);
System.out.println("branch=" + branch)

Потом он запускает тест, читает лог, добавляет еще логи, снова запускает, потом удаляет временные вставки. Работает, но долго и грязно. Если проблема внутри подключенной библиотеки, println туда просто так не вставишь.

В Veai 5.8 появился Debug Mode. Агент может поставить breakpoint, запустить код под отладкой, посмотреть переменные, шагнуть внутрь метода и проверить гипотезу на исполнении.

Лог отвечает на вопрос: "Что программа напечатала?" Debugger отвечает на другой вопрос: "Что лежит в памяти в этой точке?"

Причина runtime-ошибки часто проявляется только во время исполнения: неверное состояние объекта, неправильная ветка бизнес-логики, ошибка сериализации, порядок вызовов, edge case. Здесь Veai выигрывает не потому, что удачно догадался, а потому что проверил гипотезу в отладчике.

Instrumentation и call tree

Отладчик помогает, но иногда нужна не одна точка, а путь исполнения. Какие методы реально вызвались? С какими аргументами? Как тест прошел через сервисы?

Instrumentation позволяет плагину собирать данные под капотом без вставки логов в код.

Это полезно для flaky tests, runtime-ошибок и генерации тестов из реального исполнения. Агент получает не предположение о том, что должно было вызваться, а фактический call tree.

Здесь хорошо видно отличие продукта от обычного чата. Модель по-прежнему продолжает контекст по вероятностным паттернам. Но продукт может добавить в этот контекст структуру файла, результат теста, значения переменных, call tree и coverage. Чем больше проверенных данных, тем меньше приходится полагаться на правдоподобность ответа.

Coverage: добить конкретную дыру

Генерация тестов уже не выглядит магией. Агент может написать тесты, которые компилируются и даже поднимают процент покрытия.

Но важен не сам процент, а то, что именно покрыто.

Если модель пишет тесты по статическому коду, она может обойти сложные ветки, edge cases и исключения. Процент растет, а качество покрытия остается спорным.

Veai может получать coverage из IDE и использовать его как обратную связь. Агент видит, какие участки не покрыты, и дописывает тесты под конкретную дыру или quality gate команды.

Цикл становится честнее: не "напиши тесты, которые выглядят нормально", а "посмотри, что осталось непокрытым, и закрой это".

Review: модель читает diff, IDE проверяет системно

AI-review часто сводится к чтению diff. Модель может заметить странную архитектуру, плохое имя, подозрительную ветку. Но она не обязана одинаково внимательно проверить каждую строчку на warnings, nullability, style, resource leaks или security-проблемы.

IDE inspections закрывают именно эту скучную системную часть. Они детерминированные, поэтому полезные.

В Veai review может опираться на diagnostics, warnings/errors, inspections и SAST, а не только на рассуждение модели. Это особенно важно, когда агент сам сгенерировал код. Нужен не красивый комментарий к diff, а проверка: не внес ли он дефект.

Skills: правила команды не нужно повторять в каждом промпте

Частая ситуация: агент сделал рабочий код, но не по правилам команды.

Формально задача закрыта. На практике разработчик все равно правит стиль, тесты, обработку ошибок или процесс ревью.

В Veai 5.9 появились Skills и глобальные Skills. В 5.10 добавили поиск SKILL.md в dot-директориях других инструментов и подсветку найденных Skills.

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

Пример Skill-правил для реального workflow:

- Не делать review после каждого маленького шага.
- Сначала довести фичу до работающего состояния.
- После правок запускать конкретную IDE run configuration.
- Не редактировать файлы вне согласованного scope.
- Перед дорогими действиями спрашивать подтверждение.

Если агент этого не видит, он начинает достраивать картину по косвенным признакам.

Тарификация только за реальную работу модели

Мы меняем модель тарификации для персональных пользователей: вместо никому непонятных кредитов теперь используем поминутную оплату по времени работы модели над запросом. Речь идёт именно о compute-time — времени, которое модель тратит на обработку запроса и возврат ответа, а не о времени вашей сессии или работы в IDE.

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

При этом в подписке по-прежнему доступны все топовые модели: Opus, Sonnet, GPT, Haiku, Gemini, а также open source модели вроде GLM, MiniMax, Qwen и Kimi.

Субагенты помогают не во всех задачах

В 5.9 появились субагенты и режимы Plan, Code with subagents и Code review orchestrated. На бумаге звучит логично: большая задача, несколько агентов, параллельная работа.

Но у многоагентности есть неприятная деталь: она легко становится дорогой. Если разделить задачу неудачно, агенты пересказывают друг другу контекст, теряют детали на handoff и тратят токены на координацию.

Практичнее делить работу не по ролям, а по границам контекста.

Плохая декомпозиция:

• один агент планирует;

• второй пишет код;

• третий пишет тесты;

• четвертый ревьюит ту же фичу.

Им всем нужен один и тот же контекст. На каждом переходе часть смысла теряется.

Более удачный вариант:

• один сабагент исследует независимый модуль;

• другой проверяет отдельную зависимость;

• третий делает blackbox-проверку результата;

• оркестратор собирает короткие выводы.

Так сабагент изолирует шум, а не размазывает его по всему чату.

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

Большая техническая статья "Опыт использования субагентов в AI‑агенте для IDE: что реально работает на больших задачах, а что нет"

SAST: находка становится частью работы агента

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

В Veai 5.11 SAST встроен в IDE и связан с агентом. Запуск идет из чата по кнопке со щитом. Плагин собирает Maven/Gradle-проект, запускает анализ скомпилированных исходников и показывает результаты в IDE.

Для разработчика тут важны три вещи.

Первая: результат находится рядом с кодом. Дерево уязвимостей можно группировать по критичности, файлам, папкам и категориям.

Вторая: для многих находок есть trace от source до sink. Можно кликнуть на шаг и увидеть нужное место в редакторе.

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

После этого можно спрашивать:

• это реальная уязвимость или false positive?

• как она воспроизводится?

• какой минимальный фикс?

• что сломается, если валидировать здесь?

• какой CVSS-скор?

Veai SAST делает межпроцедурный taint-анализ: отслеживает путь данных от source до sink через методы, сервисы, объекты и виртуальные вызовы. Для JVM-проектов отдельно важны Spring DI, JPA stored-инъекции и Kotlin coroutines (suspend, async/await, Deferred).

В итоге SAST перестает быть отчетом где-то сбоку. Агент пишет или правит код, IDE и SAST дают проверенные сигналы, агент помогает разобраться и исправить.

Большую техническую статью можно почитать "SAST прямо в IDE: как Veai ищет уязвимости в Java/Kotlin-проекте и помогает их исправлять"

Edit scope: агенту полезно ограничивать руки

У слабых моделей часто две крайности: они либо не доделывают задачу, либо делают лишнее.

Пользователь просит обновить тесты в billing, а агент трогает shared utils, соседний пакет и конфигурацию CI. Потом приходится просить откатить лишнее, проверять diff, снова запускать тесты.

Edit scope решает инженерную проблему. Пользователь указывает файлы и папки, где агенту можно редактировать. Если модель пытается выйти за границы, плагин не дает ей этого сделать.

Для enterprise-кода это важно. Хороший агент должен уметь делать больше, но у него должны быть технические ограничения на лишние действия.

Что изменилось в 5.8-5.11

Почему это меняет устройство агента

LLM делает то же, что и раньше: строит вероятное продолжение контекста. Разница в самом контексте.

Шумный контекст:

IDE-контекст:

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

Смысл Veai 5.8-5.11 не в абстрактной автономности. Автономность без данных просто быстрее размножает ошибки. Здесь агент сильнее привязан к источникам, которыми разработчики уже пользуются каждый день.

Где остаются вопросы

У такого подхода есть проблемы.

• Во-первых, режимы должны быть понятны. Code, Review, Orchestrator, Skills, субагенты, MCP и SAST дают много возможностей, но пользователь должен видеть, что сейчас активно и почему.

• Во-вторых, многоагентность стоит включать аккуратно. Если задача не делится по чистым границам контекста, сабагенты могут потратить больше, чем сэкономят.

• В-третьих, Skills должны быть наблюдаемыми. Команде важно видеть, какой Skill выбран, почему он применился и как заменить дефолтный процесс своим.

• В-четвертых, компрессия длинного чата должна объяснять, что сохранилось. Иначе пользователь будет подозревать, что агент забыл важное ограничение.

Это не отменяет ценность релизов. Скорее показывает следующий фронт работы: чем больше агент умеет, тем важнее прозрачность его состояния.

Вывод

Veai 5.8–5.11 стал ближе к реальному IDE-процессу разработки.

Он запускает проект через настроенные run configurations, смотрит структуру файлов, открывает фактический код зависимостей, использует debugger вместо временных логов, делает Rename через проектную модель IDE, видит diagnostics и inspections после редактирования, использует coverage и SAST как обратную связь. Для больших задач подключает Skills, субагентов и компрессию контекста.

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