SberDevices собрала агентов фронтенда на GigaChat для ревью merge request

В SberDevices решили не отдавать код на ревью внешним сервисам и собрали собственную систему агентов для фронтенда. Готовые GitHub Copilot Code Review и GigaCode Agent из GitVerse в эту схему не вписались: оба внешние, а команда не хочет открывать им свои репозитории. Об архитектуре на Хабре рассказала Аврора, она отвечает за инфраструктуру фронтенда в компании. В анонсе нет метрик, поэтому ниже разобрано то, что подтверждено, и инженерная логика решений.

Почему своё, а не готовое

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

В основе системы лежит GigaChat. Заголовок материала противопоставляет агентов «с GigaChat и без», то есть автоматизацию с моделью и классические подходы.

Два режима в одной системе

Главное архитектурное решение: команда скомбинировала два подхода и не стала выбирать один.

• Агентный цикл. Модель получает цель и набор инструментов, а дальше сама решает, какие шаги делать. Он гибкий, но менее предсказуемый.
• Детерминированный workflow. Модель выполняет отдельные ограниченные задачи внутри заданной последовательности. Результат проще проверять и воспроизводить.

Гибрид здесь выглядит разумно. Ревью merge request состоит из узких операций: найти типовую ошибку, проверить соглашение, оценить конкретный фрагмент. Их выгоднее зашить в жёсткий сценарий. Открытые задачи вроде «разберись и предложи правку» лучше отдавать циклу с инструментами. Первое даёт стабильность, второе охват.

Что обещано в полном разборе

Автор выделяет три темы:

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

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

Какая именно функция стала самой востребованной, из анонса неизвестно. Остаётся ждать полный текст.

Что из этого взять в работу

Если вы строите внутреннего AI-ревьюера или агента для разработки, из подхода SberDevices можно взять несколько вещей.

Разделите задачи по степени свободы. Всё, что поддаётся чёткому алгоритму, делайте детерминированным workflow, а агентный цикл оставьте для открытых задач.

Не скармливайте модели весь репозиторий. Сначала сузьте контекст парсером или статическим анализом, потом вызывайте LLM.

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

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

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