На форуме 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. Делимся результатами.

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

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

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

Авторская колонка CMO Veai

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

Это уже не будущее. Это ежедневная реальность - для команд разработки и для команд маркетинга одновременно.

Но именно сейчас, когда это время наконец появилось, возникает по-настоящему важный вопрос: а куда мы, собственно, идем?

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

Поэтому самый важный навык нашего времени - не освоить очередной инструмент. А научиться правильно ставить цель и видеть, что стоит за ней: какую ценность она защищает, какой результат на самом деле нужен. Именно это определяет, куда в итоге придет агент - и вся команда вместе с ним.

Бесконечный backlog с P0 у каждого тикета

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

Доставлять фичи быстрее - P0. Качество кода - P0. Безопасность - P0. Семья - P0. Здоровье - P0. Рост команды - P0.

Классический тайм-менеджмент здесь ломается: нельзя «просто расставить приоритеты», когда все одинаково важно. Работает только одно: понять, какую ценность защищает каждый тикет. Тогда конфликт между целями становится управляемым.