# GigaChat проверяет ваш код: как SberDevices собрали AI-ревьюера для GitLab без внешних сервисов
Каноническая страница: https://plainews.ru/posts/ai-reviewer-gitlab-gigachat-sberdevices
Опубликовано: 2026-10-14T07:01:44.529Z

SberDevices запустили собственного AI-ревьюера на GigaChat-2-Max — 4000 MR, 90 проектов, без внешних сервисов. Разбираем архитектуру и код.
GitHub Copilot Code Review и GigaCode Agent не подходят крупным компаниям с закрытым кодом — открывать репозиторий внешнему сервису никто не готов. В SberDevices решили строить своё: бот на GigaChat-2-Max, который с января по июль 2026 года проверил более 4 000 merge request в 90 проектах. Разбираем, как он устроен и что из этого получилось.

## Почему внешние решения не подошли

Когда команда фронтенда в SberDevices искала инструмент для автоматического ревью, выбор был очевиден — GitHub Copilot Code Review или GigaCode Agent от GitVerse. Оба умеют именно то, что нужно. Оба требуют отправить код на внешний сервер.

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

## Что внутри AI-ревьюера

Технически это не AI-агент в классическом смысле — без автономного цикла «цель → инструменты → действие». Workflow жёстко задан кодом: детерминированная последовательность шагов, где модель отвечает только за анализ diff и формирование комментария.

Стек: TypeScript, NestJS, GitLab Webhooks, библиотека gigachat. Модель — GigaChat-2-Max «из коробки», без дообучения. Промпт задаёт роль фронтенд-разработчика и правила комментирования: указывать конкретную строку, объяснять проблему, предлагать исправление в коде.

Цепочка шагов выглядит так:

1. В GitLab создаётся или обновляется MR — GitLab отправляет webhook боту вместе с идентификаторами проекта и MR.
2. Бот запрашивает git diff изменённых файлов через GitLab API.
3. Служебные файлы (конфиги, локи) исключаются из анализа. Каждый файл получает краткое описание и классификацию: NEEDS_REVIEW (новая логика) или APPROVED (правки в существующем контенте).
4. Файлы с пометкой NEEDS_REVIEW уходят в GigaChat.
5. Ответ модели проверяется на структуру, LGTM-комментарии отфильтровываются, остальное публикуется в MR через GitLab API.
6. В описание MR добавляется краткое резюме изменений — автоматически, без участия разработчика.

Клиент GigaChat инициализируется так:

```typescript
import GigaChat from 'gigachat';

// Создаём клиент для обращения к модели
const llmClient = new GigaChat({
  model: 'GigaChat-2-Max',
  credentials: process.env.LLM_TOKEN,
});

// Передаём модели промпт с git diff
const response = await llmClient.chat({
  temperature: 0,
  messages: inputMessages,
});
```

temperature: 0 — принципиальный момент: детерминированный вывод нужен, чтобы комментарии к одному и тому же diff были предсказуемыми, а не случайными.

## Что ловит бот: статистика за январь–июль 2026

За семь месяцев AI-ревьюер обнаружил потенциальные проблемы в 8% MR — примерно один из тринадцати. Авторы отмечают, что цифра невысокая: разработчики в команде уже прогоняют код через локальные агенты перед отправкой в ревью. Там, где бот находил проблему, он оставлял в среднем около двух замечаний, чаще — одно.

В более чем 90% случаев комментарий бота — это конкретная проблема, а не общая рекомендация. Распределение по темам:

| Категория | Доля |
| --- | --- |
| Стиль, именование, поддерживаемость | 20% |
| Ошибки логики и функционального поведения | 18% |
| Работа с null/undefined, обработка ошибок | 16% |
| Типы, API и контракты | 12% |
| Синтаксис, сборка, конфигурация | 11% |
| Производительность, UI, асинхронный код, тесты, безопасность | 23% |

Типичные примеры: код синтаксически корректен, но строит неправильный URL из-за использования не тех данных; значение не пересчитывается при изменении входного текста — интерфейс показывает устаревшее состояние; fallback на пустую строку скрывает отсутствие обязательного значения.

## Как тестировали и выкатывали

Тестирование шло в репозитории-песочнице example-micromonorepo — там собраны примеры фронтенд-сервисов и тестовые MR на разных технологиях. Бета-версию бота подключили к вебхуку песочницы и проверяли сценарии ревью в изолированной среде.

Деплой через webhook дал неожиданный бонус: после релиза обновлённая версия бота моментально стала доступна всем пользователям без каких-либо действий с их стороны.

AI-ревью включено по умолчанию для всех MR, но его можно отключить на уровне репозитория в GitLab. По факту этого почти никто не делает.

Вместе с ботом разработчик получает опцию автоматически уведомлять живых ревьюеров через корпоративный мессенджер — не нужно вручную копировать ссылку на MR и писать в канал.

## Где ломается

**Язык и фреймворк.** Бот заточен под TypeScript-фронтенд. Формально он проверит код на любом языке, который понимает GigaChat-2-Max, но качество комментариев для других стеков будет заметно хуже — промпт и правила нужно дорабатывать под каждый язык отдельно.

**Классификация файлов.** Шаг с NEEDS_REVIEW / APPROVED — детерминированная логика, написанная вручную. Если правила классификации не покрывают какой-то тип файла, бот либо пропустит его, либо отправит в модель лишнее. Это нужно мониторить по мере роста числа проектов.

**Контекстное окно.** Большие diff с изменениями в десятках файлов могут упираться в ограничения контекста модели. В статье про это не говорится явно, но парсер для сужения контекста — одна из ключевых частей системы именно по этой причине.

**Ложные срабатывания.** 8% MR с найденными проблемами — это после фильтрации LGTM и структурной проверки ответа. Сколько комментариев было отфильтровано как ошибочные — в источнике не указано.

## Что попробовать дальше

Если хотите повторить подход у себя: начните с детерминированного workflow вместо полноценного агента — проще отлаживать, проще контролировать качество. Подключение через GitLab Webhook даёт мгновенное обновление без миграций. Песочница с тестовыми MR — обязательный этап перед выкаткой на реальные репозитории.

Следующий шаг после ревьюера — агентный цикл, где модель получает цель и инструменты и сама решает, что делать. В SberDevices комбинируют оба подхода: детерминированный workflow для ревью и агентный цикл для более сложных задач фронтенд-инфраструктуры.

---

## FAQ

### Можно ли использовать эту схему с другими LLM, не только GigaChat?

Да. Библиотека gigachat специфична для GigaChat API, но архитектура бота — webhook, GitLab API, фильтрация diff — не привязана к конкретной модели. Для другой LLM достаточно заменить LLM-клиент и скорректировать промпт.

### Почему temperature выставлен в 0?

При temperature: 0 модель даёт максимально детерминированный вывод. Для code review это важно: один и тот же diff должен получать предсказуемые комментарии, а не случайные вариации от запуска к запуску.

### Как бот решает, какие файлы проверять, а какие пропускать?

Логика классификации написана вручную в коде бота. Файлы делятся на NEEDS_REVIEW (код меняет логику или функциональность) и APPROVED (правки в существующем контенте, конфиги, служебные файлы). Подробного анализа требуют только файлы из первой категории.

### Что происходит, если разработчик не согласен с комментарием бота?

В статье это не описано явно, но AI-ревью можно отключить на уровне репозитория. Финальное решение по коду остаётся за живым ревьюером — бот публикует замечания как обычные комментарии в MR, а не блокирует merge.

### Насколько сложно адаптировать бота под другой язык или фреймворк?

По словам авторов, технических ограничений по языку нет — GigaChat-2-Max понимает разные языки. Но качество ревью для стека, отличного от TypeScript, будет заметно хуже. Для нормальной работы нужно переписать промпт и правила классификации под конкретный язык и фреймворк.

## Источники

- Habr AI: Может ли робот написать merge request? Агенты фронтенда с GigaChat и без