Команда встроила ИИ-агента в разработку и ввела два этапа ревью

Агент быстро написал код. Теперь кто-то должен проверить, тот ли сервис он изменил, правильную ли базу опросил и не заблокировал ли интерфейс долгой операцией. В материале на Хабре команда описала, как решала эти проблемы в собственном агенте для IntelliJ IDEA. Один из главных шагов — согласовывать спецификацию отдельным pull request до начала реализации. Такой порядок можно попробовать и с уже установленным агентом.

История началась в 2024 году с плагина для генерации тестов. Затем внутри IDE появился чат, а после знакомства с Windsurf в январе 2025 года команда взялась за полноценного агента: поиск по проекту, изменение файлов и запуск проверок. По мере использования выяснялось, какие части работы приходится объяснять заново и где инструменту нужны ограничения.

Контекст проекта: найти код и выбрать правильную базу

Для поиска команда задействовала индексы IntelliJ IDEA и PSI — структурное представление кода внутри IDE. Индексы помогают находить классы, методы и файлы, а PSI показывает элементы программы и связи между ними. Эти сведения агент передаёт языковой модели.

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

Для внешних источников команда добавила MCP — подключение серверов, которые предоставляют агенту инструменты. Через них можно получать задачи из GitHub, обращаться к базе или проверять веб-приложение в браузере. Доступные действия зависят от конкретного сервера и выданных разрешений.

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

Повторяющиеся процедуры команда оформила в skills: инструкции с порядком действий и условиями проверки. Дополнительно появилась локальная память проекта для ограничений и найденных решений. Сохранение учётных данных запрещено правилами, однако технические механизмы защиты памяти в предоставленном тексте не раскрыты.

Сначала проверить задачу, затем проверять реализацию

Теперь работа над функцией начинается со спецификации. Разработчик составляет её вместе с агентом и открывает отдельный pull request. Коллега проверяет документ, после одобрения начинается реализация. Решения и уточнения остаются в репозитории, чтобы следующий участник мог восстановить контекст.

Возьмём изменение API. До генерации кода команда может согласовать поля ответа, обработку ошибок и ожидаемое поведение клиента. Фронтенд-разработчик получает описание, которое уже проверил коллега. Здесь появляется ранняя точка проверки: ошибку в требованиях можно заметить до того, как она разойдётся по нескольким файлам.

Для ревью кода авторы использовали собственные замечания из прошлых pull request. При разработке плагина часто встречались долгие операции в потоке интерфейса EDT и обращения к IntelliJ API без необходимого read action. Эти случаи превратили в инструкции для проверяющего агента.

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

Что можно перенести в свою команду

Самый прикладной элемент истории — контроль действий на уровне плагина. Инструмент можно отключить либо потребовать подтверждение перед вызовом. Решение о запуске принимает программная оболочка. Это даёт разработчику конкретную точку контроля при работе с командами и внешними сервисами.

Команда также отделила агентскую логику от интерфейса и выпустила CLI. По её описанию, терминальная версия сохраняет работу с файлами, навыками, моделями и MCP. Однако предоставленный фрагмент обрывается: названия продукта, условий доступа и полной картины эксплуатации здесь нет.

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