GitHub Copilot Max: ИИ теперь официально одобряет pull request

28 октября 2026 года GitHub объявил о двух изменениях в Copilot code review, пишет официальный changelog GitHub: новый уровень ревью Max вышел в публичное превью, а одобрения pull request от Copilot стали общедоступны. Независимо запуск подтверждает разбор Developer-Tech: Max рассчитан на рискованные изменения вроде логики аутентификации или общей библиотеки, от которой зависят несколько сервисов, а одобрения от Copilot теперь могут засчитываться в правило обязательных ревью репозитория.

Как работает Max-уровень ревью

До сих пор у Copilot code review было два режима — Lite для быстрых проверок на каждый коммит и Balanced для повседневного ревью. Max — третий, самый тяжёлый вариант: вместо одной модели он запускает несколько независимых агентов ревью на моделях разных провайдеров, а затем агент-агрегатор сводит их находки, разрешает противоречия между ними и перепроверяет точность перед тем, как собрать единый отчёт. Из-за этого Max работает дольше и расходует больше AI-кредитов, чем Lite или Balanced, — GitHub прямо позиционирует его не как замену повседневному ревью, а как дополнительный проход для изменений с повышенным риском.

Одобрение от ИИ теперь считается

Вторая часть анонса важнее для процесса, чем сам Max. Раньше approve от Copilot был просто комментарием в духе «выглядит нормально» — он ни на что не влиял формально. Теперь, если администратор репозитория явно включил эту настройку, одобрение Copilot засчитывается в правило обязательных ревьюеров точно так же, как approve от человека. Функция выключена по умолчанию, её можно ограничить конкретными путями файлов (до 15 шаблонов), и она автоматически снимается, если после одобрения в pull request пушат новые коммиты — повторное одобрение придётся запрашивать заново.

Что это меняет в команде

Формальное право ИИ закрывать ревью — это не повод снимать ответственность с команды за то, что уезжает в прод. Правило «обязательных ревьюеров» существует не ради галочки в настройках репозитория, а чтобы кто-то разбирающийся в контексте проекта посмотрел на изменение перед мёржем; автоматизация этого правила не отменяет саму задачу. Поэтому вопрос не «включать approve от Copilot или нет», а где именно в пайплайне он уместен: для рутинных PR с низким риском — вполне, а для критичных веток merge-гейт и правила CI/CD стоит проектировать отдельно, с человеком в контуре на самых чувствительных путях. Если в проекте такой пайплайн ещё не выстроен осознанно, разумнее спроектировать его один раз правильно, чем потом разбирать инцидент из-за автоматического approve там, где он не должен был сработать — для этого в команде нужна экспертиза по настройке CI/CD и merge-правил, и тут удобнее опереться на специалистов, которые проектируют такие пайплайны и правила мёржа, чем выяснять границы вручную на живых проектах.