Агенты фронтенда на GigaChat и без него

Команда SberDevices разработала внутреннюю систему AI-агентов для фронтенд-разработки, которая автоматически проверяет merge request (MR) и анализирует логи сборки. Об этом рассказала Аврора, отвечающая за инфраструктуру фронтенда. По её словам, компания не могла использовать внешние решения вроде GitHub Copilot Code Review или GigaCode Agent из-за нежелания открывать свой код, поэтому решила создать собственный инструмент.

Система сочетает два подхода: агентный цикл, где модель получает цель и инструменты, и детерминированный workflow для выполнения ограниченных задач. AI-ревьюер запускается автоматически для любого MR, но разработчик может проверить код и до создания реквеста. В основе лежит модель GigaChat-2-Max «из коробки» без дообучения; промпт задаёт роль фронтенд-разработчика, проверяющего код на TypeScript, хотя язык и фреймворк не ограничены.

Технически AI-ревьюер — не агент, а workflow, заданный кодом. При запуске ревью GitLab отправляет боту webhook с идентификаторами проекта и MR, после чего бот через API запрашивает git diff изменённых файлов. Служебные файлы исключаются, каждый файл получает краткое описание и классификацию: NEEDS_REVIEW для нового контента или APPROVED для изменений в старом. Подробный анализ проходят только файлы, меняющие логику или функциональность.

С января по июль 2026 года AI-ревьюер проверил более 4 000 MR в 90 проектах. Потенциальные проблемы найдены в 8% случаев — примерно один MR из 13. В более чем 90% случаев бот указывает на конкретную проблему, а не даёт общие рекомендации. Самая частая тема замечаний — работа с null/undefined и обработка ошибок (16%), оставшиеся 23% делят производительность, UI, асинхронный код, тесты и безопасность.

Дополнительно реализован бот Chuck Norris, который напоминает ревьюерам о забытых MR в корпоративном мессенджере. По данным за январь–август, медиана составляет 2 пинга на один MR, хотя есть рекордсмены с более чем 100 напоминаниями. Автопинг включён по умолчанию, но проект может отключить его в конфиге. Состояние процесса ревью хранится в MongoDB, а результаты — в GitLab.

Ещё одна функция системы — анализ логов упавших job. Разработчик отправляет ссылку на job в корпоративный мессенджер, бот проверяет через GitLab API, что job действительно failed, скачивает trace и с помощью самописного парсера на TypeScript выделяет лог последней упавшей команды. Затем этот фрагмент вместе с контекстом сервиса отправляется в GigaChat-2-Max. Цель — сузить контекст для модели, уменьшить количество токенов и стоимость запроса.

Все комментарии AI-ревьюера носят рекомендательный характер: после ревью код должен пройти аппрув двух разработчиков, а автор MR сам решает, согласен ли он с замечанием. Тестирование проходило в репозитории-песочнице example-micromonorepo, а подключение через вебхук позволило моментально обновлять версию бота у всех пользователей. По словам Авроры, такой подход к тестированию инфраструктурных изменений является для команды обычной практикой.