Автоматизировать код-ревью с помощью ИИ пробуют многие команды, но большинство упирается в одно: готовые сервисы заточены под GitHub и GitLab, а корпоративные CI/CD-системы остаются за бортом. Команда Content ИИ обошла это ограничение, написав тонкую интеграционную прослойку поверх уже используемого внутри компании LLM-агента.
Архитектура MVP намеренно простая. На каждый Pull Request в CI запускается отдельный шаг: Docker-контейнер с Python-инструментом забирает через API diff и метаданные PR, собирает контекст, передаёт его LLM-агенту в non-interactive режиме и публикует ответ обратно в PR в виде inline-комментариев. Python-обвязка при этом ничего не знает про ревью кода — она только готовит контекст и парсит ответ. Вся «ревьюерская» логика живёт в промпте и в модели. Такое разделение позволяет менять LLM без переписывания инфраструктуры.
| Режим контекста | Стоимость по токенам | Качество замечаний | Статус |
|---|---|---|---|
| Только diff | Минимальная | Низкое — модель не видит окружающий код | Используется |
| Полные файлы с изменениями | Средняя | Заметно выше — видны соседние методы и контекст вызова | Используется |
| Полный репозиторий | Высокая | Ожидается максимальное | Запланировано, заблокировано размером репо |
Одним из ключевых инженерных решений стал structured output: модель возвращает строго JSON с полями summary, file_path, line_start, line_end и severity. Это решает сразу несколько проблем — ответ стабильно парсится, замечание можно точно привязать к строкам diff и подсветить прямо в интерфейсе PR, а уровни критичности (critical, major, minor, info) дают разработчику понятный приоритет. Без структурированного вывода построить полноценный инструмент практически невозможно: свободный текст модели нельзя надёжно разобрать на отдельные замечания.
Промпт у команды базовый: модель просят сосредоточиться на багах, логических ошибках, проблемах безопасности и качества кода, игнорировать стилистику и форматирование, писать комментарии по-русски. Но быстро выяснилось, что качество замечаний определяется не столько формулировками промпта, сколько тем, сколько контекста получает модель. Команда протестировала три режима: только diff (дёшево, но модель «слепа» к окружающему коду), полные файлы с изменениями (хороший компромисс — модель видит соседние методы и контекст вызова) и полный репозиторий (запланированный следующий шаг, пока заблокирован размером репо в несколько гигабайт).
Главный вывод месяца использования: когда ИИ-ревьюер ошибается, причина почти всегда не в качестве модели, а в недостатке контекста. Типичный пример — внутренние библиотеки с названиями функций, похожими на стандартные, но с другим поведением. Модель, не зная об этом, генерирует ложные замечания. Решение — давать больше контекста, а не менять модель.
С точки зрения процесса инструмент сделан ассистентом, а не блокировщиком: шаг ИИ-ревью обязателен к запуску хотя бы раз, но не блокирует merge. Разработчик может согласиться с замечанием, поправить код или закрыть его как нерелевантное. Это осознанный выбор: пока у модели есть ложные срабатывания, превращать её в жёсткий gatekeeper нельзя. Переход к более строгой роли возможен по мере накопления данных о точности замечаний и снижения доли ошибок.
