Как мы автоматизировали код-ревью благодаря связке Aider + LLM

Представьте: ревьюер час вычитывает ваш код, находит пару опечаток и забытый null-чек. А через неделю в проде всплывает серьезная уязвимость, которую никто не заметил. Знакомая ситуация[1] ^[1]? Ручное код-ревью отнимает уйму времени, и человеческий фактор может сыграть злую шутку. Неудивительно, что автоматизированное AI-ревью кода набирает популярность. По данным GitHub, более миллиона разработчиков начали использовать ИИ-ревью в первый месяц после релиза GitHub Copilot для пулл-реквестов (апрель 2025)[2] ^[2]. И это не просто хайп — технология реально меняет процесс разработки. В одном из кейсов время проверки кода сократилось с 30 до 10 минут, а количество багов в продакшене упало на 10%[3] ^[3]. Разработчики меньше тонут в рутине, больше думают об архитектуре.

Меня зовут Константин Репин, я старший программист в Fix Price. В этой статье расскажу, как мы облегчили жизнь нашим коллегам-ревьюерам, внедрив в процесс AI-ассистента для код-ревью. Начну с краткого описания инструмента, а затем перейдем к практике — покажу нашу реализацию и поделюсь опытом ^[4], включая примеры кода.

Почему мы решили автоматизировать ревью

С ростом команды и проектов код-ревью стало узким местом: опытные разработчики тратят часы на просмотр чужих pull request’ов, пытаясь выловить и стилистические огрехи, и потенциальные баги. Объемы изменений порой велики, внимание ^[5] рассеивается, а люди устают — в итоге возможны пропущенные проблемы. Классика: либо ревью превращается в формальность, либо затягивается на дни[4] ^[6]. Нам захотелось снять часть этой нагрузки с людей. Генеративные модели уже показывали себя в ускорении разработки (подсказывали код, генерировали шаблоны), почему бы не поручить им и первичное ревью?

Идея AI-ревьюера витала в воздухе. Например, на одном корпоративном хакатоне команда за 48 часов собрала MVP AI-ревью, настолько они поверили в потенциал нейросетей[5] ^[7][6] ^[8]. Эксперимент подтвердил, что автоматизация код-ревью не только возможна, но и востребована[7] ^[9]. Мы в Fix Price решили не отставать от тренда и провести свой эксперимент: пусть ИИ выполняет черновую работу ревью, а живые коллеги будут фокусироваться на высокоуровневых вещах.

Aider – наш проводник в мир AI-ревью

Чтобы внедрить AI в процесс ревью, нужен связующий инструмент между нашей кодовой базой, ML-моделью и разработчиком. Мы выбрали Aider – удобное open-source приложение CLI, работающее сразу с несколькими LLM. Почему именно Aider?

Во-первых, он обеспечивает единый интерфейс для разных языковых моделей. Грубо говоря, Aider принимает наш запрос и пересылает выбранной LLM, возвращая готовый ответ (в нашем случае – комментарии к коду). Можно переключаться между моделями без изменения основного инструмента.

Во-вторых, Aider «дружит» с Git. Он умеет работать с диффами (git diff) и даже коммитить изменения. Это ключевое свойство: мы хотели, чтобы ИИ видел контекст изменений и мог отталкиваться от конкретного списка правок. Aider сам собирает diff и формирует удобный для модели запрос. Кроме того, он хранит историю диалогов (.aider.chat.history.md), что позволяет накапливать контекст между запусками. Это повысило качество ревью за счет долговременной памяти ^[10] AI – модель помнит, что советовала в прошлый раз, и не повторяется зря.

Нам важно было интегрировать инструмент в уже знакомый процесс. Aider запускается прямо в терминале, так что разработчики могут вызывать AI-ревью из командной строки, не покидая IDE. Добавим сюда поддержку множества моделей и настраиваемых промптов – и получим отличный базис для автоматизации ревью.

Как мы внедрили AI-ревью на базе Aider

Интеграция оказалась достаточно прямой. Я взял готовый Docker-образ Aider и написал скрипт на Bash для запуска ревью. Скрипт автоматически собирает нужный контекст из Git-репозитория. Что именно он делает:

1. Собирает все новые и измененные файлы в текущем коммите (с помощью git diff –staged). Создает файл staged.diff со всем диффом изменений.

2. Формирует промпт – текстовый файл с описанием наших требований к коду (о нём подробнее ниже).

3. Вызывает 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"]

Главная логика ^[11] происходит в скрипте 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 давал полезные комментарии, мало подсунуть ему код; важно указать, что считать проблемой и каким стандартам мы следуем.

Мы заранее подготовили файл с основными требованиями к коду в нашей компании: стилевые соглашения, версии платформ, архитектурные принципы. По сути, это чек-лист для ревьюера, только написанный для понимания ИИ. Вот фрагмент нашего промпта (в виде списка правил):

• осуществить полноценное ревью кода по приведенным ниже правилам;

• искать возможные ошибки ^[12] и баги в коде;

• использовать возможности 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 «помнит», что советовала, и может проверить, исправлен ли код согласно ее рекомендациям, не появилось ли чего-то нового.

На практике это выглядело как диалог с виртуальным ревьюером: нейросеть указала на проблему – разработчик поправил – нейросеть подтвердила исправление или нашла новые нюансы. Такой цикл можно повторять ^[13] до тех пор, пока ревью не станет чистым. Конечно, бесконечно гонять AI не имеет смысла, но 1-2 итерации позволяют значительно повысить качество до того, как код попадёт на финальное ревью к коллегам.

Подбираем лучшую LLM: размеры контекста решают

При внедрении стало ясно: не каждая LLM подходит для роли ревьюера. Нам нужны модели с большим контекстным окном, чтобы влез и diff, и содержимое файлов, и наш промпт. В корпоративных проектах коммиты бывают тяжеловесными – по нескольку тысяч строк, плюс требования, плюс история переписки. Это десятки тысяч токенов.

Мы протестировали несколько вариантов и в итоге остановились на DeepSeek 3, Claude 4 и в некоторых случаях Gemini 2. У этих моделей большой контекст: например, Claude 4 (Anthropic) поддерживает до ~100К токенов, а DeepSeek Coder заявлен с окном 16K[8] ^[14], что помогает захватывать даже межфайловые зависимости. Gemini 2 – перспективная модель от Google, её мы подключаем для генерации кода (о планах использования – ниже).

Отдельно скажу про эксперимент с Qwen 3 Coder (модель от Alibaba): по характеристикам она нам подходила, но на деле столкнулись с нестабильностью результатов. AI-ревью получалось неповторимым: запускаешь два раза – ответы разные. В принципе, для LLM это нормальное поведение ^[15], но нам хотелось большей предсказуемости. Мы попробовали улучшить ситуацию за счёт ещё более строгого промпта (чтобы сузить вариативность ответов). Чуть помогло, но всё же Qwen решили отложить.

В итоге выбор пал на DeepSeek, Claude и Gemini, которые показали себя наиболее адекватно на наших задачах. К слову, DeepSeek – self-hosted решение (аналитики отмечают, что такая модель из 6,7 млрд параметров может обойти даже CodeLlama 13B, давая до 70% полезных советов[9] ^[16]). Пока используем её из коробки, в паре с мощным Claude для сложной бизнес логики.

Опыт коллег: AI-ревью в СНГ и мире

Мы не единственные, кто экспериментирует с AI для ревью кода. Тема горячая, и в сообществе уже есть интересные кейсы:

• Open-Source инструменты. На Хабре появилось сразу несколько проектов от инженеров-энтузиастов. Например, AI Review – утилита, которая интегрируется в CI и автоматически добавляет комментарии к Pull Request с помощью LLM[11] ^[17]. Автор сделал ставку на простую интеграцию (буквально одной командой) и независимость от внешних сервисов. Другой пример – проект ReVu, self-hosted AI-ревьюер для PR, который анализирует diff и оставляет либо общий отчёт, либо построчные замечания прямо в коде[12] ^[18][13] ^[19]. Оба решения гибко настраиваются под свои правила и могут работать с разными провайдерами AI – хоть OpenAI, хоть локальная модель через Ollama[14] ^[20].

• Большие компании СНГ. Крупные игроки тоже в теме. «Яндекс» разрабатывает собственного ассистента Code Assistant, а Сбер развивает AI-помощника GigaCode. Эти решения позиционируются как отечественные альтернативы западным, с упором на открытый исходный код моделей[15] ^[21]. GigaCode изначально использовался внутри Сбера, а в 2024-м вышел для всех желающих[16] ^[22] – фактически наш ответ GitHub Copilot. Пока акцент у них больше на автодополнение и генерацию кода, но, очевидно, они могут лечь и в основу AI-ревью. Кстати, в платформе Сбера (GitVerse) заявлен AI-агент, который берет на себя рутинные задачи проверки кода[17] ^[23].

• Международный опыт. В мировой индустрии примеров ещё больше. Microsoft внедрила AI, обрабатывающий 600 тысяч PR в месяц, сократив медианное время ревью на 10–20%[18] ^[24]. ByteDance (владелец TikTok) запустила систему BitsAI-CR, которая с помощью мультиагентного подхода добилась точности до 75% и получила положительные отзывы от ~74% разработчиков[19] ^[25]. Google применяет ML-ассистента Critique и экономит сотни тысяч инженерных часов в год[20] ^[26]. Эти цифры впечатляют и мотивируют развивать собственные решения.

• AI vs человек. Встает логичный вопрос: а не заменит ли такой AI-ревьюер живых тимлидов? Опыт показывает, что нет – по крайней мере, пока. Скорее, ИИ становится полезным помощником. Как отмечают коллеги, AI-ревью отлично закрывает рутинные моменты, помогая джунам и экономя время синьоров, но архитектурные решения и важные нюансы по-прежнему остаются за лидом[21] ^[27]. Проще говоря, место лидов в безопасности. Наша цель – ускорить и улучшить процесс, а не заменить человека. Идеальный сценарий: AI отсеял опечатки, неправильные названия, мелкие баги, а живой ревьюер сосредоточился на сути изменений. Именно так достигается синергия: человек и машина дополняют друг друга[22] ^[28].

Итоги: что нам это дало и что дальше

Внедрив связку Aider + LLM, мы ощутили заметные плюсы. 

Во-первых, сократилось время на первичную проверку кода. Теперь многие очевидные вещи (форматирование, типовые ошибки) ловятся автоматически, и ревьюер-тимлид тратит меньше сил на рутину. 

Во-вторых, повысилось качество ревью: AI не устает и не отвлекается, поэтому не пропустит ту самую мелочь, на которую человек может махнуть рукой в пятницу вечером. Конечно, ложные срабатывания тоже бывают, и к каждому AI-совету мы подходим критично. Но даже если из всего списка рекомендаций разработчик возьмёт на вооружение пару-тройку, это уже улучшение.

В-третьих, команды стали активнее обсуждать код. Парадокс ^[29]: появление AI-комментариев спровоцировало диалог – «А почему бот предлагает так переписать? Может, и правда лучше вынести это в сервис?» То есть AI-ревью не заменяет коммуникацию, а запускает её. В итоге меньше обид на личную критику («машина же без эмоций ^[30], ей не влом проставить 100 комментариев»), и более предметный разговор о коде.

Конечно, не все замечания модели мы принимаем. Иногда ИИ ошибается или выдаёт спорные советы. Но это тоже ценно: такие случаи выявляют неявные договорённости в команде, которые стоит затем внести в тот самый промпт-регламент. Мы рассматриваем AI-ревьюера как постоянно обучаемый инструмент. Чем более точные правила мы ему дадим (и чем лучше подтюним модели под свой код), тем полезнее он будет.

Планы: на будущее хотим использовать Aider не только для ревью, но и для генерации нового кода через промпты. По сути, использовать весь богатый функционал ассистента, который может по запросу сгенерировать всю бизнес-логику, зная наши подходы. Уже экспериментируем с разными LLM для этих задач – подбираем, кто лучше справится и не галлюцинирует лишнего. Но это тема для отдельной статьи.

Подводя итог: наш опыт показывает, что автоматизация код-ревью с помощью ИИ – реально работает. Да, это не «священный Грааль», и живое ревью никуда не делось. Однако связка вроде Aider + LLM уже сегодня снимает часть нагрузки с команды, повышает качество кода и ускоряет выпуск features. Если вы ещё не пробовали такой инструмент – самое время поэкспериментировать. Начните с небольшого проекта, выберите удобную модель (или локальное решение) и сформируйте для нее четкий список требований. Результат вас может приятно удивить. Ведь, как говорится, будущее разработки наступает прямо сейчас, и те, кто научится работать с AI-инструментами, получат серьезное преимущество[23] ^[31]. Успехов в экспериментах и чистого вам кода!

Ссылки:

• Опыт внедрения AI-ревью в крупных IT-компаниях и тренды (WebProd, VK)[24] ^[2][18] ^[24]

• О��крытый инструмент AI Review для CI/CD (sound_right)[11] ^[17][25] ^[32]

• Hackathon-марафон по созданию AI-ревьюера за 48 часов (Oleg Akulov)[5] ^[7][7] ^[9]

• Self-hosted AI-ревьюер ReVu и принципы его работы (proDream)[12] ^[18][13] ^[19]

• Сравнение AI-ассистентов кодинга и упоминание GigaCode (Sber)[15] ^[21][16] ^[22]

• Дискуссия «AI vs Team Lead» на Хабре (M.Video ^[33])[21] ^[27] и комментарии про роль AI в ревью[22] ^[28]

---

[1] ^[1] [2] ^[2] [3] ^[3] [8] ^[14] [9] ^[16] [15] ^[21] [18] ^[24] [19] ^[25] [20] ^[26] [23] ^[31] [24] ^[2] Как внедрить автоматическое ревью кода с помощью ИИ: опыт Microsoft, Google и ByteDance + практическое руководство / Хабр

https://habr.com/ru/articles/940318/ ^[34]

[4] ^[6] [5] ^[7] [6] ^[8] [7] ^[9] Как мы автоматизировали код-ревью за 48 часов на хакатоне: от боли ^[35] техлидов до рабочего MVP / Хабр

https://habr.com/ru/articles/942288/ ^[36]

[10] ^[37] [25] ^[32] AI Review кода за 30 минут: локальная LLM прямо в CI/CD / Хабр

https://habr.com/ru/articles/953598/ ^[38]

[11] ^[17] AI Review: инструмент для автоматического ревью кода на основе LLM / Хабр

https://habr.com/ru/articles/951434/ ^[39]

[12] ^[18] [13] ^[19] [14] ^[20] [22] ^[28] ReVu — Open Source AI-ревьюер для ваших Pull Request / Хабр

https://habr.com/ru/articles/954860/?utm_source=habrahabr&utm_medium=rss&utm_campaign=954860 ^[40]

[16] ^[22] GigaCode и все-все-все. Сравниваем различные ИИ-ассистенты между собой / Хабр

https://habr.com/ru/companies/sberbank/articles/816107/ ^[41]

[17] ^[23] У разработчиков появился новый виртуальный помощник для …

https://sbertech.ru/news/u-razrabotchikov-poyavilsya-novyj-virtualnyj-pomoshhnik-dlya-proverki-koda-na-platforme-git-verse-ot-sbera ^[42]

[21] ^[27] Code Review с помощью ИИ: замена лиду или помощь стажеру?

https://habr.com/ru/companies/mvideo/articles/952668/ ^[43]