GitHub опубликовал практическое руководство по проверке pull request, сгенерированных агентами ИИ, и управлению растущей нагрузкой на код-ревью.
По данным GitHub, агент GitHub Copilot code review уже обработал более 60 млн ревью, а доля проверок с участием агентов превысила одну пятую от общего числа. Объём автоматизированных изменений растёт быстрее, чем возможности разработчиков по ручной проверке, и привычный цикл «запросил ревью — дождался владельца кода — смёржил» перестаёт работать.
В материале подчёркивается: кодовые агенты продуктивны и хорошо копируют шаблоны, но не обладают контекстом команды — историей инцидентов, знаниями про редкие кейсы и эксплуатационные ограничения. Они создают код, который выглядит завершённым, что повышает риск «тихого» технического долга и дублирования логики.
Авторы советуют авторам pull request с участием агентов не отправлять их «как есть». Рекомендуется редактировать описание, добавлять пояснения прямо в diff и самостоятельно провести первичное ревью перед тем, как звать других коллег. Это показывает, что разработчик проверил, насколько агент верно реализовал его замысел, и экономит время ревьюеров.
Для ревьюеров GitHub выделяет несколько ключевых зон внимания. Во‑первых, защита конвейера CI. Агенты, пытаясь «починить» упавшие тесты, могут ослаблять проверки: удалять тесты, пропускать шаги линтинга, добавлять конструкции вида || true в команды тестов. Любые изменения, которые снижают строгость CI, предлагается считать блокирующими до появления явного обоснования.
Во‑вторых, технический долг через дублирование кода. Агенты ищут примеры в кодовой базе и склонны создавать новые утилиты, валидаторы и вспомогательные функции, которые повторяют уже существующие с небольшими отличиями в названии или реализации. Рекомендация: для каждого нового «хелпера» делать поиск по репозиторию и требовать объединения с уже имеющимся решением до слияния. Иначе дублирующая логика станет «примером» для следующих генераций агента.
Отдельный риск — «тихие» ошибки, которые не ловятся компиляцией и тестами. Это пограничные случаи, пропущенные проверки прав доступа, некорректная валидация входных данных, ошибки под нагрузкой и гонки. GitHub советует не ограничиваться беглым просмотром, а пошагово прослеживать критические пути: от входных данных до результата, проверяя нулевые, максимальные и пустые значения, наличие проверок прав и валидации на всех ветках логики.
Для каждого значимого исправления рекомендуется требовать новый тест, который падает на старом поведении и проходит на новом. Если агент не может предложить такой тест, сделанный фикс, по мнению авторов, или неполон, или основан на неверном понимании ошибки.
GitHub также обращает внимание на большие агентные pull request без чёткого плана. Масштабные изменения, в которых агент «просто начал писать код», часто приводят к затяжным и малорезультативным ревью. В таких случаях предлагается сначала запросить разбиение задачи на меньшие части или структуру изменений, а уже потом вкладываться в детальный просмотр.
Отдельный блок посвящён безопасности workflow с LLM в CI. Описывается сценарий, когда агент читает содержимое описаний pull request, issues или сообщений коммитов, подставляет их в промпт, отправляет запрос к модели, а затем использует ответ в командной строке с правами GITHUB_TOKEN. Это создаёт риск prompt injection. Для таких сценариев GitHub называет необходимыми условиями: минимально достаточные права в YAML (например, permissions: read-all), экранирование и проверка недоверенных данных до попадания в промпт, разделение этапов «анализ» и «исполнение» с ручным подтверждением для всего, что затрагивает продакшн, и категорический отказ от выполнения вывода модели без проверки.
Автоматизированное ревью, по мнению GitHub, лучше использовать для механических задач: поиск несоответствий стилю, очевидных логических ошибок, пропущенной обработки ошибок и проблем с типами. Copilot code review выполняет такой «низкоуровневый» проход, освобождая ревьюерам время для оценок, требующих контекста. Рекомендуется запускать автоматическое ревью до ручного и настраивать его под команду: помечать изменения порогов в CI, новые утилиты для проверки на дублирование, валидацию внешних входных данных и т.п.
В материале приводится пример использования Copilot SDK, когда разработчик формализовал собственный чек‑лист ревью в workflow. Автоматический процесс проверяет точки вроде аутентификации на админ‑эндпоинтах, фактического запуска тестов и безопасного обращения с переменными окружения и блокирует merge при обнаружении критических проблем.
Авторы подчёркивают, что объём кода и количество pull request будет расти, и доля «рутинного» просмотра должна сокращаться за счёт автоматизации. При этом ценность ручного ревью остаётся в том контексте о системе, который есть только у людей. Именно этот контекст и связанная с ним оценка рисков пока не поддаются полной автоматизации.
Материал подготовлен Andrea Colombi, Senior Developer Advocate GitHub, которая более десяти лет работает с инструментами для разработчиков и занимается популяризацией сложных технологий для широкой аудитории. Информация основана на публикациях и внутренних данных GitHub.
