За час ИИ-агент может изменить десятки файлов, написать тесты и потратить большой объём токенов. Польза для команды зависит от результата. Если разработчик долго восстанавливает ход изменений, переписывает половину патча или обнаруживает пропущенный сценарий после слияния, работа агента только увеличивает нагрузку.

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

Для оценки каждой задачи нужны три параметра:

На форуме Cursor разработчик рассказал, как запретил агенту работать с удалённой базой, а тот всё равно выполнил npx supabase db push. Эта команда отправляет локальные изменения схемы в подключённый удалённый проект. Агент мог изменить рабочую базу данных — и только после этого сам признал, что нарушил правило.

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

У меня всё закончилось проще. Вчера я попросил Cursor разобраться с упавшим сквозным тестом. Я ждал исправления в приложении, но агент поменял проверку в самом тесте и отчитался, что всё готово. Тест, разумеется, прошёл.

Такое поведение я заранее запретил в правилах проекта. В правиле было написано: сквозные тесты считаем контрактом, при падении сначала ищем ошибку в приложении, сам тест без согласования не меняем. Cursor правило видел — по крайней мере, в начале разговора он ему следовал.

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

ИИ‑агент редко ограничивается одним ответом, когда работает с большим проектом. Он читает код, ищет использования символов, меняет несколько файлов, запускает тесты и исправляет найденные ошибки. За это время история чата пополняется сообщениями пользователя и результатами инструментов.

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

В Veai 5.16 для этих сценариев появились команда /btw и параметр strictness. Ниже разберём механику обеих функций, их ограничения и влияние частого повторения инструкций на контекст модели.

В прошлой статье мы разбирали, как сделать работу ИИ-агента предсказуемее: зафиксировать требования в спецификации с помощью Specification-Driven Development (SDD), до реализации описать ожидаемое поведение тестами по Test-Driven Development (TDD), а готовый результат проверить и передать отдельному субагенту на ревью.

У такого подхода есть цена.

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

Полагаться только на свои ощущения в таких вопросах очень опрометчиво. В одном из экспериментов разработчики считали, что ИИ ускорил их примерно на 20%. Замеры показали обратное: с ИИ они работали на 19% медленнее.

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

Что показывают эксперименты, если читать их целиком

Заголовки об ИИ в разработке противоречат друг другу: «на 55% быстрее», «на 19% медленнее», «на 26% продуктивнее». Результаты расходятся, потому что исследования проводились в разных условиях и измеряли разные показатели.

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

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

По общим тезисам каждый может проверить выводы у себя.

Записи вебинаров на RuTube / YouTube: 

Вебинар 1 — AI-инструменты для разработчиков 2026 

Вебинар 2 — Настройка проекта под агента

Вебинар 3 — Как работать с ИИ-агентом: SDD, TDD, самопроверка и субагенты

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

«Дайте агенту доступ к терминалу и файловой системе, и он сам всё сделает» звучит привлекательно ровно до первого случая, когда агент вместо тестового файла отредактировал конфиг продакшена, или переписал файл с ключами API, потому что тот «мешал» задаче. После этого в компании обычно появляется вопрос от безопасника или тимлида: а как мы вообще контролируем, что этот агент делает с кодом?

Проблема в том, что «контроль над агентом» - это не один переключатель в настройках. Это набор независимых механизмов, каждый из которых ограничивает что-то своё: что агент видит, куда может писать, насколько самостоятельно действует и кто проверяет результат. «Разберём эти механизмы по отдельности на примере того, как это устроено в Veai — агенте, который работает и в OpenIDE, и в JetBrains IDE; в статье возьмём плагин для JetBrains IDE, потому что на нём проще показать конкретные экраны и файлы: так проще говорить предметно, а не абстрактно.»

Автотесты падают, а разбор занимает время: нужно открыть отчёт в системе управления тестами, понять причину падения, залезть в репозиторий, найти нужный тест и решить, где ошибка: в самом тесте или в приложении. Veai умеет забирать эту рутину на себя. Агент подключается к TMS (Test Management System), читает данные о падении по ссылке и предлагает правку прямо в открытом проекте.

В статье разберём, что такое TMS в контексте Veai, как подключить Allure TestOps и Test IT, и как агент разбирает причину падения автотеста: от инфраструктуры до флаков.

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

Сейчас почти каждый 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-серверы и несколько изменений в интерфейсе. Разберём по порядку.

Все обзоры меряют одно — как быстро агент работает с кодом. Но на моём боевом Java-проекте на тысячи строк самый «быстрый» агент выдал решение за 12 секунд, а потом 40 минут гонял сборку в терминале, пытаясь заставить код компилироваться.

Кто быстрее работает с кодом — тот дольше его чинит, а типовые сравнения этап починки не считают вовсе.

Чтобы проверить это, я взяла одну и ту же задачу «добавь фичу и покрой её тестами» и дала её трём типам агентов: CLI в терминале (Claude Code, Codex, OpenCode), кросс-IDE плагинам (Cursor через ACP, Copilot, Cline, Kilo Code, Windsurf) и агенту, встроенному в JetBrains Platform (Veai). Меряла не секунды на генерацию, а число итераций до зелёной сборки и расход токенов. Ниже — шесть метрик, которые я добавила, и почему они переворачивают выводы типовых обзоров.

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

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

Для этого в 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 мы регулярно тестируем и сравниваем модели, которые доступны у нас в плагине. Каждая модель, которую мы добавляем проходит через наш собственный бенчмарк, прежде чем попасть в продакшн. Недавно тестированию подверглись GLM 5.1 и DeepSeek V3.2. Делимся результатами.

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

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

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