Ревью кода с ИИ: политика, в которой последнее слово за человеком

Политика ревью кода с ИИ закрепляет для команды одно непреложное правило: ИИ может писать и анализировать код, но за его слияние отвечает конкретный человек. В каждом изменении, подготовленном с помощью ИИ, нужно раскрыть, как именно он применялся, пройти детерминированные проверки и организовать человеческое ревью, строго соразмерное возможному ущербу.

Сейчас это разграничение особенно важно. 17 августа 2026 года Wiz сообщила о критической уязвимости типа injection в GitHub Actions в публичном репозитории Snowflake. В итоговом squash-коммите Copilot Autofix был указан как соавтор, а проверка безопасности GitHub с поддержкой ИИ не обнаружила проблем. При этом Wiz отдельно подчеркнула: неизвестно, применялся ли ИИ при самом изменении кода. Через пять дней после появления уязвимости автономный агент безопасности нашёл и эксплуатировал её в рамках санкционированного тестирования.

Почему команды всё равно стремятся к автоматизации, хорошо видно из экономики процесса. Если команда обрабатывает 50 pull request в неделю и тратит по 30 минут на первичную ручную проверку каждого, это 25 инженерных часов. При условной полной стоимости часа в $120 получается $3,000 в неделю — ещё до углублённого ревью. Сейчас GitHub оценивает одну проверку Copilot в $0.05–$1 в ИИ-кредитах при уровне Lite или в $0.25–$5 при уровне Balanced, не считая минут GitHub Actions. Первичная проверка становится дешёвой. Право одобрить изменение — нет.

Что на самом деле задаёт такая политика

Хорошая политика не запрещает ИИ, а регулирует движение кода. Она объясняет автору, что нужно раскрыть, автоматике — что блокировать, а ревьюеру — в каких случаях обязателен ещё один человек.

Представьте pull request как груз, прибывший в порт. Тесты и сканеры осматривают контейнер. ИИ-ревьюер читает декларацию и отмечает подозрительные места. Но решение о пересечении границы всё равно принимает человек. Если отдать инструменту проверки печать должностного лица, сам контроль теряет смысл.

Основу политики можно сформулировать так:

Код, созданный или существенно изменённый с помощью ИИ-инструмента для разработки, допускается только через pull request. Автор обязан понимать изменение и указать использованный инструмент, объём помощи ИИ, выполненные тесты и ответственного человека. До одобрения должны успешно завершиться все обязательные тесты и проверки безопасности. Ревью с помощью ИИ носит рекомендательный характер и никогда не засчитывается как обязательное человеческое одобрение. Для чувствительных файлов нужен владелец кода. Критические изменения требуют второго независимого согласующего и плана отката. Каждый новый коммит аннулирует прежнее одобрение и запускает ревью заново.

Эта политика опирается на последствия, а не на попытку установить авторство. Разработчику не нужно доказывать, какие именно строки появились благодаря автодополнению. Достаточно заявить о существенной помощи ИИ и принять ответственность за весь diff. Это полезнее, чем спорить о проценте, который ни один инструмент всё равно не способен превратить в решение об одобрении.

Разделите ревью на три уровня

Критический уровень намеренно обходится дорого. На него должна приходиться лишь малая доля изменений. Дефицитное внимание старших специалистов нужно направлять туда, где одна правдоподобно выглядящая ошибка способна раскрыть учётные данные, повредить данные или изменить права доступа.

Как работает политика ревью кода с ИИ — без жаргона

В процессе шесть контрольных точек. Каждая оставляет свидетельства, которые может проверить следующий ревьюер.

1. Заявите о помощи ИИ. Добавьте в шаблон pull request поля AI-assisted, tool, scope, human owner и tests run. Автор отвечает за каждую строку — независимо от того, написал ИИ одну функцию или весь первый вариант.
2. Определите риск. Небольшой файл политики сопоставляет пути и типы изменений с Обычным, Чувствительным или Критическим уровнем. Изменение в .github/workflows/ не должно попадать в одну категорию с исправлением опечатки в документации.
3. Сначала запустите детерминированные проверки. Детерминированность означает, что один и тот же ввод всегда даёт одинаковый результат — пройдено или не пройдено. Соберите проект, проверьте типы и стиль, выполните тесты, найдите секреты, проанализируйте зависимости и проведите статический анализ безопасности, прежде чем просить ещё одну модель высказать мнение. В собственных рекомендациях GitHub по ревью автоматические тесты и статический анализ также стоят на первом месте.
4. Используйте ИИ как критика. Поручите ему искать пропущенные сценарии, расхождения с архитектурой, удалённые тесты, выдуманные API, подозрительные пакеты и изменения прав. Для работ, затрагивающих безопасность или несколько сервисов, выбирайте более глубокий режим проверки. Самопроверка агента, который написал код, не должна закрывать контрольную точку.
5. Вердикт выносит человек. Ревьюер проверяет замысел, тестирует рискованное поведение, ставит под сомнение новые зависимости и решает, место ли этому diff в системе. Комментарии ИИ — лишь наводки, пока человек или детерминированный инструмент не подтвердит проблему.
6. Сбрасывайте ревью после каждого push. Отзывайте устаревшие одобрения, повторно запускайте обязательные проверки и запрашивайте новое ревью после появления новых коммитов. GitHub отмечает, что автоматическое ревью Copilot обычно выполняется один раз, если не включена проверка при каждом push.

В политику стоит включить ещё два неочевидных ограничения. Во-первых, файлам зависимостей нужен отдельный сканер, поскольку GitHub Copilot code review исключает такие файлы, как package.json и Gemfile.lock. Во-вторых, изменения инструкций для ИИ нужно считать критическими. Copilot читает инструкции репозитория, инструкции агентов и skills из head-ветки pull request — значит, предлагаемое изменение способно поменять правила, по которым его будут ревьюить.

Семь сценариев, где политика окупится в первую очередь

1. Платформенные команды, запускающие агентов разработки во множестве репозиториев

Больше всего выиграют команды платформенной инженерии: одна политика сможет управлять тысячами будущих изменений. Вынесите карту рисков в общий шаблон, везде требуйте одинаковые поля декларации и предоставьте единственную status check, понятную каждой защищённой ветке. Результат — централизованный контроль без необходимости каждой продуктовой команде изобретать собственный ритуал. Команды, которые сравнивают лучших ИИ-агентов для корпоративной разработки, смогут менять инструменты, не перестраивая модель одобрения.

2. SaaS-команды, защищающие аутентификацию, биллинг и клиентские данные

Руководитель разработки SaaS-продукта может отнести код аутентификации, проверки прав, платежей и экспорта данных к Критическому уровню. Агент вправе подготовить исправление, а ИИ-ревьюер — разобрать его, но одобрение должны дать владелец системы идентификации или платежей и ещё один человек. Так старшие специалисты не тратят одинаковое время на каждый файл, а сосредоточиваются на изменениях с реальным радиусом поражения.

3. DevOps-команды, поддерживающие процессы CI/CD

Считайте файлы workflow исполняемой production-инфраструктурой. Каждое изменение направляйте владельцу кода из DevOps, проверяйте прямую подстановку недоверенного содержимого issue или pull request в команды оболочки, контролируйте разрешения токенов и требуйте план отката. Случай Wiz наглядно показывает пользу: заголовок публичного issue попал в команду оболочки, а раскрытый токен позволял читать внутренние проекты Jira. Политика ловит сам класс ошибки ещё до спора о том, кто был исходным автором — человек или ИИ.

4. Руководители разработки, внедряющие Copilot, Codex или Claude Code

Ответственный за внедрение может разделить право пользоваться инструментом и право сливать код. Разработчики получают быструю генерацию и первичное ревью, а правила защиты ветки по-прежнему требуют человеческого одобрения, успешного выполнения workflow и проверки владельцем кода. Результат — внедрение с контролем, который можно аудировать. Обзор локального режима и режима GitHub в Codex поможет выбрать инструмент, но при смене поставщика человеческая контрольная точка должна сохраниться.

5. Мейнтейнеры open source, получающие pull request без контекста

Добавьте в CONTRIBUTING.md чекбокс об использовании ИИ и список обязательных подтверждений, а автоматике поручите отклонять заявки без шагов воспроизведения, тестов или ответственного мейнтейнера. ИИ может составлять резюме и предварительно разбирать очередь. Люди сосредоточатся на замысле, совместимости и уместности вклада для проекта. Так долг по ревью уменьшается без негласного снижения планки для незнакомых участников.

6. Агентства, передающие ПО клиенту

Агентство может прилагать к каждому релизу квитанцию о ревью: использованные инструменты, затронутые компоненты, результаты тестов, нерешённые замечания и имена согласующих. Чувствительные клиентские пути до релиза отправляются владельцу кода со стороны клиента. Это делает ответственность прозрачнее и оставляет артефакт передачи, который сохранится после ухода команды исполнителя.

7. Соло-фаундеры, выпускающие продукт с ИИ-агентом разработки

У соло-фаундера по умолчанию нет независимого коллеги, поэтому разделение ролей приходится создавать самим процессом. Пусть одна модель готовит код, затем выполняются детерминированные проверки и отдельный проход ревью, после чего основатель лично проверяет рискованный сценарий перед слиянием. Для платежей, аутентификации или production-инфраструктуры привлеките внешнего специалиста. Это недорогой первичный фильтр — без притворства, будто вторая модель равна второму ответственному человеку.

Что можно построить на этой основе

Рынок уже платит за автоматизированное ревью. Спрос в Google в США составляет около 1,600 поисковых запросов в месяц для "ai powered code review platform", 1,300 — для "ai code review" и 590 — для "ai code review tools". Сейчас CodeRabbit берёт $24 за разработчика в месяц на годовом тарифе Pro и $48 на Pro Plus. Тарифы Qodo начинаются с $30 в месяц. Свободная ниша — не ещё один бот, который комментирует каждый pull request, а управляющий слой, определяющий, какое ревью действительно засчитывается.

1. Контрольная точка pull request по принципу Policy as Code — самая сильная возможность

Создайте GitHub App для руководителей разработки и безопасности, который превращает короткий файл политики в обязательные проверки. Он читает изменённые пути, проверяет декларацию об использовании ИИ, назначает уровень риска, вызывает нужных владельцев кода, убеждается в запуске обязательных сканеров, аннулирует устаревшее одобрение и формирует аудиторскую квитанцию.

Спрос подтверждает потенциал категории: "ai powered code review platform" получает около 1,600 поисковых запросов в США ежемесячно, а "ai code review" — 1,300 при CPC $63.85. Минимальная версия, которую уже можно продавать, включает GitHub App, файл политики репозитория, status check, сервис маршрутизации ревьюеров и таблицу аудита. Главный риск — усталость от настройки. Продукт победит только в том случае, если хорошие значения по умолчанию покроют распространённые стеки, а исключения будет легко объяснить.

2. Маршрутизатор ревью для критических файлов

Можно создать более узкий инструмент для платформенных команд и AppSec. Он отслеживает такие пути, как workflow, инфраструктура, миграции, аутентификация и файлы политик, после чего повышает глубину ревью, вызывает нужного владельца и требует повторной проверки после каждого push. Обычный код можно пропускать через недорогой проход, сохраняя дорогостоящий анализ и время людей для критических diff.

"AI code review tools" получает около 590 поисковых запросов в США ежемесячно, имеет коммерческий интент и показывает годовой рост 50% в наборе ключевых слов. Запрос "secure code review" добавляет 170 поисков в месяц при CPC $50.19. Для MVP нужны правила путей, интеграция с CODEOWNERS, интерфейс check run и маршрутизация ревью с учётом бюджета. Главная опасность — расползание категории. Инструмент должен дополнять SAST, поиск секретов и анализ зависимостей, а не выдавать себя за их замену.

3. Квитанция о происхождении изменений с ИИ

Создайте лёгкий CLI и бот для pull request, ориентированный на агентства и регулируемые команды. Он фиксирует заявленный инструмент, идентификатор сессии, изменённые файлы, выполненные тесты, решения ревьюеров и конечного ответственного человека, а затем формирует подписанную квитанцию релиза. Документ должен подтверждать соблюдение процесса, а не пытаться угадать авторство по стилю кода.

Около 210 поисковых запросов в США ежемесячно приходится на "ai generated code detector", CPC составляет $16.70. За этим спросом стоит реальная тревога, но обещание детектировать авторство — неправильный продукт. Продаваемая версия вместо этого даёт покупателю доказательства ревью и ответственности. Слабое место — участие: если команда способна обойти декларацию, квитанция превращается в театр. Защита веток и интеграция идентификации — основа продукта, а не необязательные дополнения.

Свободна и ниша авторитетного источника. Проверка цитирования в ChatGPT не выявила регулярно цитируемых материалов по запросу "ai code review tools". Продукт, который опубликует строгую версионируемую схему политики и прозрачные механизмы контроля, сможет стать ориентиром, одновременно продавая систему исполнения этих правил.

Ограничения и честный вывод

Ревью с ИИ — полезный фильтр, но не доказательство безопасности. GitHub предупреждает, что Copilot review способен пропускать проблемы и его необходимо дополнять человеческой проверкой. Он также исключает некоторые файлы, может переключиться на менее функциональный режим при недоступности runner и останавливается после исчерпания бюджета ИИ-кредитов. Ни одно из этих условий не должно незаметно снижать требования к слиянию.

У агентного автоисправления та же граница применимости. Система GitHub в режиме public preview умеет исследовать кодовую базу, предлагать исправление, повторно запускать CodeQL и открывать черновой pull request — часто за две–четыре минуты. GitHub также указывает, что система работает по принципу best effort, не может подтвердить исправление некоторых пользовательских или расширенных для безопасности запросов и не гарантирует качество исправлений для оповещений сторонних инструментов. Зелёный повторный запуск доказывает лишь то, что один детектор перестал жаловаться. Он ничего не доказывает о бизнес-поведении, модели разрешений или безопасности окружающего workflow.

Эта политика не решает задачи определения авторства, слабых тестов, нехватки архитектурных знаний или культуры бездумного одобрения pull request. Она также окажется слишком тяжёлой, если каждая опечатка попадёт на Критический уровень. Оставляйте Обычный уровень дешёвым, Критический — малым и никогда не превращайте инструмент, создавший изменение, в единственную инстанцию, которая его одобряет.

Что сделать в понедельник

В понедельник руководителю разработки стоит добавить в шаблон pull request пять полей: AI-assisted, tool, scope, human owner и tests run. Затем нужно отнести .github/workflows/, аутентификацию, платежи, production-инфраструктуру, секреты и деструктивные миграции к Критическому уровню. Для этих путей потребуйте успешный CI, ревью владельцем кода, отзыв устаревших одобрений и второго человека. Этого достаточно, чтобы превратить мнение о коде с ИИ в первую работающую версию правил.

Нужно ли проверять код, написанный ИИ?

Да. Сначала запустите тесты и детерминированные сканеры, затем используйте ИИ как дополнительного критика, а ответственность за слияние закрепите за конкретным человеком. Ревью с ИИ не должно засчитываться как обязательное человеческое одобрение.

Может ли ChatGPT проводить ревью кода?

ChatGPT может разобрать diff, указать на недостающие тесты и заметить подозрительную логику. Но он не способен обеспечить защиту ветки, доказать выполнение CI или отвечать за последствия в production. Используйте его внутри политики, а не вместо неё.

Какой ИИ лучше всего подходит для ревью кода?

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

Есть ли бесплатный инструмент для ревью кода с ИИ?

Бесплатные или уже включённые компоненты существуют. Классический Copilot Autofix от GitHub не требует подписки Copilot и не расходует ИИ-кредиты для подходящих репозиториев, а существующие инструменты CI могут обеспечить многие детерминированные проверки. Полноценная политика всё равно требует настройки и участия человека.

Если хотите встроить такую контрольную точку ревью в инженерный процесс, посмотрите решения для production-систем с ИИ.