Как внедрить автоматическое ревью кода с помощью ИИ: опыт Microsoft, Google и ByteDance + практическое руководство

[alexhott]

Это смотря какую цель преследует ревью кода в вашей компании.
Если вы хотите чтобы все соблюдали требование архитектуры, красиво расставляли скобочки и не допускали косяков типа нул поинтер ексепшен, то да годно и с моделью.

Там где я работал ревью кода в первую очередь было инструментом обмена опытом, обучения, и развития коммуникаций в командах, а с функцией контроля архитектуры, безопасности и синтаксиса и простые библиотеки справлялись с описанными правилами.

Не знаю насколько такая эффективность в долгосрочной перспективе сыграет

[WebProd]

Из нашего опыта и кейсов в статье складывается такая картина: AI берёт на себя рутину (те самые скобочки, null pointer, очевидные проблемы безопасности), освобождая время для того самого ценного обмена опытом.

Например, в Microsoft отметили интересный эффект — когда разработчики перестали тратить время на поиск тривиальных ошибок, качество дискуссий в ревью значительно выросло. Вместо "забыл проверку на null в строке 42" обсуждают "а почему мы выбрали именно такой паттерн для этой задачи?".

Google пошёл дальше — их ML-suggested edits покрывают только 7.5% комментариев, остальные 92.5% остаются за людьми. При этом экономия времени колоссальная, потому что эти 7.5% — самые времязатратные и скучные проверки.

Поэтому вижу это как "И-И", а не "ИЛИ-ИЛИ": AI для рутины + люди для менторинга и архитектурных решений = больше времени на действительно важные обсуждения.

[vbvictor]

А сравнивались ли AI ревью с code formatter / code linter? Все разговоры "о скобочках" и "null dereference" потенциально решаются уже существующими детерминированными инструментами.

Зачастую в проектах форматтинг/линтинг очень плохо развит поэтому кажется что AI начинает давать сразу большой буст

[WebProd]

Вы абсолютно правы — базовые проверки форматирования и простые баги типа null dereference действительно эффективнее решаются детерминированными инструментами.

Я привёл упрощённые примеры для наглядности, можно их немного усложнить:

1. Контекстно-зависимые проблемы

# Линтер не увидит проблему:
def process_payment(amount, user_id):
    if amount > 1000:
        notify_admin(user_id)  # AI: "А где проверка прав пользователя?"
    return charge_card(amount)

2. Бизнес-логика и edge cases
В ByteDance 40% полезных комментариев AI касались именно логических ошибок: "При таком условии заказ может быть обработан дважды" или "Этот расчёт не учитывает часовые пояса".

3. Security beyond SAST
AI находит проблемы типа "Этот endpoint раскрывает внутреннюю структуру БД через error message" — формально код корректен, но есть риск.

Вы правы насчёт "плохо развитого линтинга" — часто команды сначала внедряют AI, а потом понимают, что 30% его работы можно заменить правильно настроенным ESLint + Prettier + SonarQube. Всегда как в пирамиде потребностей нужно двигаться снизу вверх: сначала линтеры, дальше уже надстройка над ними.

[vic_1]

AI берёт на себя рутину (те самые скобочки, null pointer, очевидные проблемы безопасности) по моему с этим справляются статический анализатор. Не знаю по стоимости, на проекте мы использовали SonarQube, как раз находил подобные ошибки. А вот как раз интересен поиск концептуальных проблем, похоже ии к этому пока не готов

[WebProd]

Вы абсолютно правы насчёт статических анализаторов — SonarQube, ESLint и прочие действительно отлично справляются с базовыми проблемами. И по стоимости они часто выгоднее. Ключевое отличие AI-систем — контекстное понимание кода за счёт использования RAG (подробнее описал в ветке выше).

Но вы правы — с концептуальными архитектурными проблемами AI пока справляется плохо. Он не скажет "эта микросервисная декомпозиция избыточна" или "этот bounded context нарушает DDD принципы".
Оптимальная стратегия сейчас: SonarQube для базовых проверок + AI для контекстного анализа + человек для архитектурных решений. Это даёт лучший ROI.

[griha_shershen]

Ощущение что не только пост написала нейронка, но и комментарии пишет частично или полностю нейронка

[KoIIIeY]

Вы абсолютно правы!

1. Пишет человек

2. Точно человек

[rodion-m]

А кто автор статьи? Действительно выглядит как генерация.

DeepSeek Coder с 6,7 миллиардами параметров после дообучения превосходит CodeLlama с 13 миллиардами, достигая 70% полезных предложений против 40-50%.

Это же какие-то совсем старые неактуальные модели, почему тут про них написано? Мелкие модели для code review - это в принципе прямой путь к зашкаливающим ложным срабатываниям.

Расскажите как именно и что именно вы внедрили - вот это будет интересно прочитать.

[WebProd]

DeepSeek Coder и CodeLlama действительно уже не самые актуальные. Упомянул их в контексте исследования ByteDance (https://arxiv.org/pdf/2501.15134), где они экспериментировали с разными размерами моделей для оптимизации latency/quality трейдофа. Сейчас, конечно, все переходят на GPT-5, Claude 4, Gemini Pro для критических проверок.

P.S. Да, статью помогал структурировать Claude, но весь фактический материал — из публичных рейсов компаний. В эпоху AI было бы странно не использовать его для улучшения текста, как мы используем IDE для написания кода :) Мы внедрение только начали и этот анализ проводился как изучение best-practices дабы не наступать на чьи-то грабли. Статья с нашими результатами будет как наберётся достаточное количество данных для анализа результатов.