Представьте: ревьюер час вычитывает ваш код, находит пару опечаток и забытый null-чек. А через неделю в проде всплывает серьезная уязвимость, которую никто не заметил. Знакомая ситуация[1]? Ручное код-ревью отнимает уйму времени, и человеческий фактор может сыграть злую шутку. Неудивительно, что автоматизированное AI-ревью кода набирает популярность. По данным GitHub, более миллиона разработчиков начали использовать ИИ-ревью в первый месяц после релиза GitHub Copilot для пулл-реквестов (апрель 2025)[2]. И это не просто хайп — технология реально меняет процесс разработки. В одном из кейсов время проверки кода сократилось с 30 до 10 минут, а количество багов в продакшене упало на 10%[3]. Разработчики меньше тонут в рутине, больше думают об архитектуре.
Привет, Хабр! Меня зовут Константин Репин, я старший программист в Fix Price. В этой статье расскажу, как мы облегчили жизнь нашим коллегам-ревьюерам, внедрив в процесс AI-ассистента для код-ревью. Начну с краткого описания инструмента, а затем перейдем к практике — покажу нашу реализацию и поделюсь опытом, включая примеры кода.
Почему мы решили автоматизировать ревью
С ростом команды и проектов код-ревью стало узким местом: опытные разработчики тратят часы на просмотр чужих pull request’ов, пытаясь выловить и стилистические огрехи, и потенциальные баги. Объемы изменений порой велики, внимание рассеивается, а люди устают — в итоге возможны пропущенные проблемы. Классика: либо ревью превращается в формальность, либо затягивается на дни[4]. Нам захотелось снять часть этой нагрузки с людей. Генеративные модели уже показывали себя в ускорении разработки (подсказывали код, генерировали шаблоны), почему бы не поручить им и первичное ревью?
Идея AI-ревьюера витала в воздухе. Например, на одном корпоративном хакатоне команда за 48 часов собрала MVP AI-ревью, настолько они поверили в потенциал нейросетей[5][6]. Эксперимент подтвердил, что автоматизация код-ревью не только возможна, но и востребована[7]. Мы в Fix Price решили не отставать от тренда и провести свой эксперимент: пусть ИИ выполняет черновую работу ревью, а живые коллеги будут фокусироваться на высокоуровневых вещах.
Aider – наш проводник в мир AI-ревью
Чтобы внедрить AI в процесс ревью, нужен связующий инструмент между нашей кодовой базой, ML-моделью и разработчиком. Мы выбрали Aider – удобное open-source приложение CLI, работающее сразу с несколькими LLM. Почему именно Aider?
Во-первых, он обеспечивает единый интерфейс для разных языковых моделей. Грубо говоря, Aider принимает наш запрос и пересылает выбранной LLM, возвращая готовый ответ (в нашем случае – комментарии к коду). Можно переключаться между моделями без изменения основного инструмента.
Во-вторых, Aider «дружит» с Git. Он умеет работать с диффами (git diff) и даже коммитить изменения. Это ключевое свойство: мы хотели, чтобы ИИ видел контекст изменений и мог отталкиваться от конкретного списка правок. Aider сам собирает diff и формирует удобный для модели запрос. Кроме того, он хранит историю диалогов (.aider.chat.history.md), что позволяет накапливать контекст между запусками. Это повысило качество ревью за счет долговременной памяти AI – модель помнит, что советовала в прошлый раз, и не повторяется зря.
Нам важно было интегрировать инструмент в уже знакомый процесс. Aider запускается прямо в терминале, так что разработчики могут вызывать AI-ревью из командной строки, не покидая IDE. Добавим сюда поддержку множества моделей и настраиваемых промптов – и получим отличный базис для автоматизации ревью.
Как мы внедрили AI-ревью на базе Aider
Интеграция оказалась достаточно прямой. Я взял готовый Docker-образ Aider и написал скрипт на Bash для запуска ревью. Скрипт автоматически собирает нужный контекст из Git-репозитория. Что именно он делает:
Собирает все новые и измененные файлы в текущем коммите (с помощью git diff --staged). Создает файл staged.diff со всем диффом изменений.
Формирует промпт – текстовый файл с описанием наших требований к коду (о нём подробнее ниже).
Вызывает Aider, передавая ему staged.diff, историю предыдущих ревью .aider.chat.history.md, список изменённых файлов и наш промпт-сообщение.
С помощью переменных окружения мы настроили Aider под свои нужды (модель по умолчанию, автокоммиты отключены, цветовую схему и пр.). Разработчики запускают скрипт, и Aider отправляет сформированный запрос в LLM, не внося никаких изменений в код – только чтение и анализ. В ответ получает от модели замечания по измененному коду.
Ниже приведён пример настройки сервиса у себя через docker-compose (фрагмент из нашего docker-compose.yml):
version: '3.8'
services:
aider:
container_name: ${CONTAINER_NAME_PREFIX}_aider
build:
context: ./aider
dockerfile: Dockerfile
volumes:
- ../:/${PROJECT_PATH}/ # примонтировать корень проекта внутрь контейнера
- ./aider/aider-entrypoint.sh:/aider-entrypoint.sh
- ./aider/aider-review-author-commits.sh:/aider-review-author-commits.sh
environment:
- AIDER_MODEL=${AIDER_MODEL}
- DEEPSEEK_API_KEY=${DEEPSEEK_API_KEY}
- AIDER_AUTO_COMMITS=${AIDER_AUTO_COMMITS}
- AIDER_GIT=${AIDER_GIT}
- AIDER_WATCH_FILES=${AIDER_WATCH_FILES}
- AIDER_SUBTREE_ONLY=${AIDER_SUBTREE_ONLY}
- AIDER_READ=${AIDER_READ}
- AIDER_DARK_MODE=${AIDER_DARK_MODE}
- AIDER_AUTHOR_COMMITS=${AIDER_AUTHOR_COMMITS}
stdin_open: true
tty: true
user: "${AIDER_UID}:${AIDER_GID}"
working_dir: /${PROJECT_PATH}/
entrypoint: ["bash", "/aider-entrypoint.sh"]Dockerfile для контейнера предельно прост — фактически берём исходный образ Aider и добавляем Git:
FROM paulgauthier/aider
USER root
RUN apt-get update && apt-get install -y git
WORKDIR /app
CMD ["aider"]Главная логика происходит в скрипте aider-entrypoint.sh. Вот ключевой фрагмент, где формируется контекст изменений и запускается Aider:
git diff --staged > staged.diff
mapfile -t STAGED_FILES < <(git diff --staged --name-only --diff-filter=M)
aider staged.diff .aider.chat.history.md "${STAGED_FILES[@]}" \
--message="$(cat $AIDER_READ)" "$@"Здесь мы сохраняем diff индексированных изменений в staged.diff. Затем получаем список изменённых файлов STAGED_FILES. Наконец, вызываем Aider, передавая ему: файл diff, историю прошлых ревью, все изменённые файлы и --message – содержимое файла с промптом (переменная $AIDER_READ указывает на текстовый файл, где сформулировано задание для ревью).
Таким образом, LLM получает полную картину: и патч со всеми изменениями, и сами файлы целиком, и наши требования к качеству. Благодаря этому модель видит и контекст правок, и может заглянуть в код, чтобы понимать окружающую логику.
Чему мы научили AI: промпт с нашими требованиями
Отдельно остановлюсь на промпте – инструкциях, которые мы передаем модели перед ревью. Чтобы AI давал полезные комментарии, мало подсунуть ему код; важно указать, что считать проблемой и каким стандартам мы следуем.
Мы заранее подготовили файл с основными требованиями к коду в нашей компании: стилевые соглашения, версии платформ, архитектурные принципы. По сути, это чек-лист для ревьюера, только написанный для понимания ИИ. Вот фрагмент нашего промпта (в виде списка правил):
осуществить полноценное ревью кода по приведенным ниже правилам;
искать возможные ошибки и баги в коде;
использовать возможности PHP 8.3 (актуальная версия на проекте);
придерживаться принципов SOLID;
соблюдать стандарты PSR-4 и PSR-12;
проверять, что названия переменных осмысленные и соответствуют контексту (никаких x, temp и т.п.);
генерировать интерфейсы для сервисного слоя, если они напрашиваются;
выносить бизнес-логику из контроллеров (контроллер должен быть "тонким", все зависимости через DI);
в контроллерах проводить валидацию входящих данных;
ответы контроллеров оформлять в виде DTO, реализующих JsonSerializable;
использовать строгий Dependency Injection в сервисах;
ActiveRecord-модели строго типизировать и использовать связи (relations) при наличии;
не помещать бизнес-логику в ActiveRecord-модели;
миграции БД должны быть атомарными и поддерживать откат;
...и так далее.
Полный список правил довольно объемный, но суть в том, что мы даем модели четкое представление о наших стандартах. Например, если в коде найдётся нарушение PSR-12 или отсутствие DI в контроллере, AI должен это заметить и указать.
Важно: мы попросили LLM выдавать замечания в виде примеров кода с комментариями. То есть, если модель рекомендует исправить что-то, она показывает, как именно – небольшим патчем или фрагментом кода, сопровождая пояснением. Такой формат похож на то, как реальный ревьюер написал бы комментарий в MR.
После того как Aider отправил промпт и код в LLM, начинается само ревью. Модель анализирует изменения и генерирует вывод: список замечаний, рекомендаций, иногда хвалит за удачные решения ?. Все эти AI-комментарии выводятся прямо в консоли разработчика. Наша практика – если отзыв оказался дельным, разработчик правит код и коммитит исправления.
Повторное ревью по следам исправлений
А что если после правок хочется ещё раз прогнать AI-ревью, чтобы проверить, всё ли учтено? Для этого мы добавили возможность повторного запуска ревью с учётом предыдущего результата.
Как это реализовано: Aider, как я упоминал, хранит историю переписки с моделью (.aider.chat.history.md). Там остаются и замечания AI, и контекст, который был при прошлом запуске. Если разработчик после первого ревью внес изменения и снова запускает скрипт, Aider передаст модели всю историю, включая прежние комментарии. LLM «помнит», что советовала, и может проверить, исправлен ли код согласно ее рекомендациям, не появилось ли чего-то нового.
На практике это выглядело как диалог с виртуальным ревьюером: нейросеть указала на проблему – разработчик поправил – нейросеть подтвердила исправление или нашла новые нюансы. Такой цикл можно повторять до тех пор, пока ревью не станет чистым. Конечно, бесконечно гонять AI не имеет смысла, но 1-2 итерации позволяют значительно повысить качество до того, как код попадёт на финальное ревью к коллегам.
Подбираем лучшую LLM: размеры контекста решают
При внедрении стало ясно: не каждая LLM подходит для роли ревьюера. Нам нужны модели с большим контекстным окном, чтобы влез и diff, и содержимое файлов, и наш промпт. В корпоративных проектах коммиты бывают тяжеловесными – по нескольку тысяч строк, плюс требования, плюс история переписки. Это десятки тысяч токенов.
Мы протестировали несколько вариантов и в итоге остановились на DeepSeek 3, Claude 4 и в некоторых случаях Gemini 2. У этих моделей большой контекст: например, Claude 4 (Anthropic) поддерживает до ~100К токенов, а DeepSeek Coder заявлен с окном 16K[8], что помогает захватывать даже межфайловые зависимости. Gemini 2 – перспективная модель от Google, её мы подключаем для генерации кода (о планах использования – ниже).
Отдельно скажу про эксперимент с Qwen 3 Coder (модель от Alibaba): по характеристикам она нам подходила, но на деле столкнулись с нестабильностью результатов. AI-ревью получалось неповторимым: запускаешь два раза – ответы разные. В принципе, для LLM это нормальное поведение, но нам хотелось большей предсказуемости. Мы попробовали улучшить ситуацию за счёт ещё более строгого промпта (чтобы сузить вариативность ответов). Чуть помогло, но всё же Qwen решили отложить.
В итоге выбор пал на DeepSeek, Claude и Gemini, которые показали себя наиболее адекватно на наших задачах. К слову, DeepSeek – self-hosted решение (аналитики отмечают, что такая модель из 6,7 млрд параметров может обойти даже CodeLlama 13B, давая до 70% полезных советов[9]). Пока используем её из коробки, в паре с мощным Claude для сложной бизнес логики.
Опыт коллег: AI-ревью в СНГ и мире
Мы не единственные, кто экспериментирует с AI для ревью кода. Тема горячая, и в сообществе уже есть интересные кейсы:
Open-Source инструменты. На Хабре появилось сразу несколько проектов от инженеров-энтузиастов. Например, AI Review – утилита, которая интегрируется в CI и автоматически добавляет комментарии к Pull Request с помощью LLM[11]. Автор сделал ставку на простую интеграцию (буквально одной командой) и независимость от внешних сервисов. Другой пример – проект ReVu, self-hosted AI-ревьюер для PR, который анализирует diff и оставляет либо общий отчёт, либо построчные замечания прямо в коде[12][13]. Оба решения гибко настраиваются под свои правила и могут работать с разными провайдерами AI – хоть OpenAI, хоть локальная модель через Ollama[14].
Большие компании СНГ. Крупные игроки тоже в ��еме. «Яндекс» разрабатывает собственного ассистента Code Assistant, а Сбер развивает AI-помощника GigaCode. Эти решения позиционируются как отечественные альтернативы западным, с упором на открытый исходный код моделей[15]. GigaCode изначально использовался внутри Сбера, а в 2024-м вышел для всех желающих[16] – фактически наш ответ GitHub Copilot. Пока акцент у них больше на автодополнение и генерацию кода, но, очевидно, они могут лечь и в основу AI-ревью. Кстати, в платформе Сбера (GitVerse) заявлен AI-агент, который берет на себя рутинные задачи проверки кода[17].
Международный опыт. В мировой индустрии примеров ещё больше. Microsoft внедрила AI, обрабатывающий 600 тысяч PR в месяц, сократив медианное время ревью на 10–20%[18]. ByteDance (владелец TikTok) запустила систему BitsAI-CR, которая с помощью мультиагентного подхода добилась точности до 75% и получила положительные отзывы от ~74% разработчиков[19]. Google применяет ML-ассистента Critique и экономит сотни тысяч инженерных часов в год[20]. Эти цифры впечатляют и мотивируют развивать собственные решения.
AI vs человек. Встает логичный вопрос: а не заменит ли такой AI-ревьюер живых тимлидов? Опыт показывает, что нет – по крайней мере, пока. Скорее, ИИ становится полезным помощником. Как отмечают коллеги, AI-ревью отлично закрывает рутинные моменты, помогая джунам и экономя время синьоров, но архитектурные решения и важные нюансы по-прежнему остаются за лидом[21]. Проще говоря, место лидов в безопасности. Наша цель – ускорить и улучшить процесс, а не заменить человека. Идеальный сценарий: AI отсеял опечатки, неправильные названия, мелкие баги, а живой ревьюер сосредоточился на сути изменений. Именно так достигается синергия: человек и машина дополняют друг друга[22].
Итоги: что нам это дало и что дальше
Внедрив связку Aider + LLM, мы ощутили заметные плюсы.
Во-первых, сократилось время на первичную проверку кода. Теперь многие очевидные вещи (форматирование, типовые ошибки) ловятся автоматически, и ревьюер-тимлид тратит меньше сил на рутину.
Во-вторых, повысилось качество ревью: AI не устает и не отвлекается, поэтому не пропустит ту самую мелочь, на которую человек может махнуть рукой в пятницу вечером. Конечно, ложные срабатывания тоже бывают, и к каждому AI-совету мы подходим критично. Но даже если из всего списка рекомендаций разработчик возьмёт на вооружение пару-тройку, это уже улучшение.
В-третьих, команды стали активнее обсуждать код. Парадокс: появление AI-комментариев спровоцировало диалог – «А почему бот предлагает так переписать? Может, и правда лучше вынести это в сервис?» То есть AI-ревью не заменяет коммуникацию, а запускает её. В итоге меньше обид на личную критику («машина же без эмоций, ей не влом проставить 100 комментариев»), и более предметный разговор о коде.
Конечно, не все замечания модели мы принимаем. Иногда ИИ ошибается или выдаёт спорные советы. Но это тоже ценно: такие случаи выявляют неявные договорённости в команде, которые стоит затем внести в тот самый промпт-регламент. Мы рассматриваем AI-ревьюера как постоянно обучаемый инструмент. Чем более точные правила мы ему дадим (и чем лучше подтюним модели под свой код), тем полезнее он будет.
Планы: на будущее хотим использовать Aider не только для ревью, но и для генерации нового кода через промпты. По сути, использовать весь богатый функционал ассистента, который может по запросу сгенерировать всю бизнес-логику, зная наши подходы. Уже экспериментируем с разными LLM для этих задач – подбираем, кто лучше справится и не галлюцинирует лишнего. Но это тема для отдельной статьи.
Подводя итог: наш опыт показывает, что автоматизация код-ревью с помощью ИИ – реально работает. Да, это не «священный Грааль», и живое ревью никуда не делось. Однако связка вроде Aider + LLM уже сегодня снимает часть нагрузки с команды, повышает качество кода и ускоряет выпуск features. Если вы ещё не пробовали такой инструмент – самое время поэкспериментировать. Начните с небольшого проекта, выберите удобную модель (или локальное решение) и сформируйте для нее четкий список требований. Результат вас может приятно удивить. Ведь, как говорится, будущее разработки наступает прямо сейчас, и те, кто научится работать с AI-инструментами, получат серьезное преимущество[23]. Успехов в экспериментах и чистого вам кода!
Ссылки:
Опыт внедрения AI-ревью в крупных IT-компаниях и тренды (WebProd, VK)[24][18]
Открытый инструмент AI Review для CI/CD (sound_right)[11][25]
Hackathon-марафон по созданию AI-ревьюера за 48 часов (Oleg Akulov)[5][7]
Self-hosted AI-ревьюер ReVu и принципы его работы (proDream)[12][13]
Сравнение AI-ассистентов кодинга и упоминание GigaCode (Sber)[15][16]
Дискуссия «AI vs Team Lead» на Хабре (M.Video)[21] и комментарии про роль AI в ревью[22]
[1] [2] [3] [8] [9] [15] [18] [19] [20] [23] [24] Как внедрить автоматическое ревью кода с помощью ИИ: опыт Microsoft, Google и ByteDance + практическое руководство / Хабр
https://habr.com/ru/articles/940318/
[4] [5] [6] [7] Как мы автоматизировали код-ревью за 48 часов на хакатоне: от боли техлидов до рабочего MVP / Хабр
https://habr.com/ru/articles/942288/
[10] [25] AI Review кода за 30 минут: локальная LLM прямо в CI/CD / Хабр
https://habr.com/ru/articles/953598/
[11] AI Review: инструмент для автоматического ревью кода на основе LLM / Хабр
https://habr.com/ru/articles/951434/
[12] [13] [14] [22] ReVu — Open Source AI-ревьюер для ваших Pull Request / Хабр
https://habr.com/ru/articles/954860/?utm_source=habrahabr&utm_medium=rss&utm_campaign=954860
[16] GigaCode и все-все-все. Сравниваем различные ИИ-ассистенты между собой / Хабр
https://habr.com/ru/companies/sberbank/articles/816107/
[17] У разработчиков появился новый виртуальный помощник для ...
[21] Code Review с помощью ИИ: замена лиду или помощь стажеру?
Daemonis
а в чем разница между ошибкой и багом? :)
heejew
Баги могут превратиться в фичи или быть частью ТЗ, а ошибки - нет