Почему большие AI-PR убивают качественное ревью — и как это исправить
Размер имеет значение: как ограничить изменения, потребовать объяснимость и не позволить автоматизации подменить критическое мышление
Скорость без тормозов
Cursor к апрелю 2025 года отчитался о генерации одного миллиарда строк кода в день [1]. GitHub сообщает, что более 97% опрошенных разработчиков хотя бы однажды использовали AI-инструменты в работе. AI ускорил написание кода — это факт. Но процесс ревью не стал быстрее.
Faros AI в июне 2025 года измерил показатели 10 000+ разработчиков из 1255 команд. Результат выглядит обескураживающе: при высоком AI-adoption размер PR вырос на 154%, время ревью — на 91%, число инцидентов на PR — на 23,5%, а change failure rate — на 30% [2]. Метрики DORA не улучшились. Шаг написания кода ускорился; шаг проверки — нет.
Это не проблема инструментов. Это проблема архитектуры ревью-процесса, который не был рассчитан на такую нагрузку.
Что говорят данные: AI-код и его качество
Исследование CodeRabbit на базе 470 open-source Pull Request показало: AI-генерированный код создаёт в 1,7 раза больше issues по сравнению с написанным людьми [3]. Рекуррентные категории — логика, корректность, читаемость, безопасность.
Veracode в своём анализе 2025 года зафиксировал: 45% AI-сгенерированного кода содержало уязвимости из OWASP Top 10 [4]. Java показывал особенно высокий процент провалов — более 70%. Это не экзотика: SQL injection (CWE-89), XSS (CWE-79), небезопасная десериализация — типичные паттерны, воспроизводимые моделями потому, что они оптимизированы под функциональность, а не под безопасность.
Ещё один слой риска — галлюцинации зависимостей. Исследование 576 000 кодовых сэмплов на 16 LLM, опубликованное в USENIX Security 2025, показало: в 19,7% случаев рекомендованные пакеты не существуют [5]. Для некоторых open-source моделей показатель достигает 22%; у коммерческих, включая GPT-4, — около 5%, что тоже значимо. 58% галлюцинированных пакетов повторяются между запросами — это делает их предсказуемыми целями для атак типа slopsquatting [6].
Sonar в январе 2026 опубликовал данные по «верификационному разрыву»: 96% разработчиков не доверяют AI-коду полностью, но далеко не все его проверяют. 38% говорят, что ревью AI-кода требует больше усилий, чем ревью кода коллег [7]. 61% согласны с тем, что AI-код «выглядит правильным, но не всегда надёжен» — то есть ошибки в нём труднее заметить, чем типичные ошибки человека.
Clutch опросил 800 специалистов в июне 2025: 59% признали, что используют AI-код, который не вполне понимают [8]. Это не небрежность — это системный эффект automation bias: человек склонен доверять автоматизированным системам больше, чем следует, особенно когда вывод выглядит профессионально [9].
Почему большие PR разрушают ревью
Связь между размером PR и качеством ревью хорошо задокументирована.
SmartBear в исследовании практик Cisco зафиксировал: эффективность ревью резко падает при изменениях свыше 200–400 строк [10]. Не потому что код стал лучше — а потому что когнитивная усталость заставляет рецензента переходить в режим «просмотра», а не «анализа». Анализ 50 000+ PR от Propel Code показал: PR размером более 1000 строк имеют на 70% более низкий процент обнаружения дефектов, при этом PR до 200 строк апрувятся в три раза быстрее [11].
Google внутренне придерживается правила: изменения (CL, changelists) должны быть минимальными — затрагивать только одну проблему, включать тесты и содержать всё необходимое для понимания в описании [12]. Инженерные практики Google явно предупреждают: большой CL, отправленный на ревью, означает, что при принципиально неверном направлении весь объём работы может оказаться потраченным впустую.
С приходом AI эта проблема обострилась. Разработчик с agentic-ассистентом может открыть за день столько PR, сколько команда раньше делала за спринт [13]. При этом рецензент сталкивается с кодом, который выглядит как написанный опытным инженером, но не несёт в себе никаких следов авторского мышления, архитектурного контекста и понимания trade-off'ов.
Исследование на arXiv (2026) о «inconsistency в Agentic-PR» прямо указывает: AI-агенты генерируют описания автоматически без человеческого надзора, создавая потенциально вводящие в заблуждение объяснения в масштабе [14]. Рецензент читает описание PR, видит разумное объяснение — и не находит его соответствия тому, что фактически сделал код.
Automation bias: невидимый риск
Помимо технической стороны, есть когнитивная. METR в июле 2025 опубликовал исследование, в котором зафиксировал разрыв между воспринимаемой и реальной производительностью: разработчики считали себя быстрее на 20%, но на деле работали медленнее на 19% [15]. Разрыв в 39 процентных пунктов объяснялся двумя механизмами.
Первый — automation bias: склонность доверять результатам автоматизированных систем, даже когда они ошибаются. Второй — effort heuristic: меньше набранных символов воспринимается как меньше проделанной работы, хотя когнитивной работы стало больше, а не меньше.
Codebridge описывает это как «18-месячную стену»: первые 3 месяца дают эйфорию от прироста скорости, но без надлежащего управления следует предсказуемый коллапс [9]. Признаки — нарастающий технический долг, неожиданные регрессии, инциденты в production.
Stack Overflow Developer Survey 2025 зафиксировал парадокс: доля использующих AI выросла до 84%+, но доля доверяющих AI упала на 11 процентных пунктов — до 29% [16]. Скептицизм нарастает, а практика проверки — нет.
Три рабочих механизма против blind trust
1. Ограничение размера изменений
Ограничение по строкам — не карательная мера, а инструмент защиты рецензента от когнитивной перегрузки.
Отправная точка: большинство исследований называют 200–400 строк рабочим диапазоном для большинства команд [10, 11, 17]. Google рекомендует стремиться к меньшему, а не большему [12]. Propel Code описывает реальный кейс: внедрение автоматических предупреждений при превышении 400 строк привело к снижению дефектов после merge на 35% [11].
Практическая реализация включает несколько уровней:
Автоматические size-checks в CI. Пример конфигурации в GitHub Actions:
- name: Check PR size
run: |
CHANGED_LINES=$(git diff --numstat HEAD~1 | awk '{sum += $1 + $2} END {print sum}')
if [ $CHANGED_LINES -gt 400 ]; then
echo "::warning::PR содержит $CHANGED_LINES строк. Рассмотрите разбивку на части."
fiЖёсткий лимит (hard limit) можно выставить на 600 строк, до которого CI не блокирует merge, но вывешивает предупреждение. Выше — требуется отдельное согласование. Microsoft Engineering Fundamentals Playbook рекомендует в качестве ориентира: одна PR = одна пользовательская история или функциональная единица [18].
Атомарные PR. Разбивка по слоям: миграция БД — отдельный PR, сервисный слой — отдельный PR, API endpoint — третий. Рефакторинг и функциональные изменения — всегда в разных PR [19]. Это не только облегчает ревью, но и упрощает откат при проблемах.
Stacked PRs. Для крупных фич — цепочка зависимых PR, каждый из которых нацелен на предыдущий, а не сразу на main [17]. При merge базового PR следующий автоматически перенацеливается.
Важная оговорка: некоторые изменения органически велики — переименование класса, массовый рефакторинг, scaffolding нового проекта. Для таких случаев разумно тегировать PR отдельно и не включать их в метрику стандартного ревью [17].
2. Требовать explainability в описании PR
Если автор не может объяснить, что и почему изменил — описание надо вернуть на доработку. Это правило работало и раньше, но в эпоху AI-кодинга оно приобрело новый смысл.
Google eng-practices прямо указывают: «Fix bug» — неприемлемое описание. Нужно отвечать на вопросы: что именно сделано, какую проблему это решает, почему выбрано именно это решение [20]. Описание должно позволять будущему инженеру (и рецензенту) понять контекст без погружения в весь diff.
Для AI-PR это требование становится критически важным. Codebridge формулирует это так: «Вы больше не можете считать, что тот, кто открыл PR, полностью понял код в нём» [13]. PR-описание — единственная точка, где можно потребовать от автора продемонстрировать понимание.
Рабочий шаблон PR-темплейта для команд с AI-кодингом включает несколько обязательных полей.
Поле «Что изменено» — краткое описание функциональных изменений без деталей реализации.
Поле «Почему именно так» — обоснование выбранного подхода: почему не альтернативный вариант, какие trade-off'ы учтены. Это поле делает видимым наличие или отсутствие авторского понимания.
Поле «Риски и влияние» — явное перечисление: что может пойти не так, какие смежные системы затронуты, нужна ли миграция данных.
Поле «Как тестировалось» — не только «тесты прошли», но и описание ручной проверки, edge cases, которые проверены.
Поле «Использовался ли AI» — честный ответ: какой инструмент, для каких частей. Это не стигматизация, а информация для рецензента о том, где сосредоточить внимание.
Последнее поле особенно важно с учётом данных о package hallucinations [5, 6]: рецензент должен знать, где AI участвовал в выборе зависимостей.
Codebridge предлагает ещё один полезный инструмент — risk-tiered review [13]: низкорисковые изменения (генерация тестов, документация, internal tooling) идут по ускоренному пути с автоматическими проверками; высокорисковые (auth, платёжная логика, infra config, всё, что касается регулируемых данных) требуют именованного рецензента с domain expertise и явного security sign-off.
3. Разбивать работу так, чтобы AI не увеличивал blind trust
Третий механизм — организационный. Он касается того, как команда структурирует задачи до начала кодирования.
Первый принцип: планирование до PR. Артси Engineering сформулировали это так: «Размер PR определяется задолго до его открытия». Если фича изначально декомпозирована на атомарные задачи, каждая из которых имеет чёткий acceptance criteria, AI-агент будет генерировать меньшие, более фокусированные изменения [19].
Второй принцип: ownership остаётся за человеком. OWASP прямо указывает: команда несёт ответственность за весь закоммиченный код, независимо от того, кто или что его написал [13]. Это означает: каждое изменение должно иметь именованного владельца, который может объяснить его логику и поддерживать его в будущем.
Третий принцип: разделение рефакторинга и функциональных изменений. Google eng-practices и Microsoft Engineering Playbook сходятся в одном: никогда не смешивать стилевые/рефакторинговые изменения и функциональные в одном PR [18, 21]. С AI это правило становится ещё важнее — агенты часто переформатируют попутно, что маскирует реальные изменения.
Четвёртый принцип: явная проверка зависимостей. Учитывая данные о slopsquatting [6], каждый PR с новыми зависимостями должен требовать явной проверки: пакет существует в официальном реестре, у него актуальная версия, нет известных advisories. Это минимум, который нельзя делегировать AI без проверки.
Пятый принцип: не автоматизировать approvals. Данные Stack Overflow о падении доверия к AI [16] и исследование Sonar о верификационном разрыве [7] говорят об одном: культура «AI сгенерировал — LGTM» разрушает ревью как механизм. Автоматические комментарии от AI-ревьюеров полезны, но не должны подменять человеческое суждение о принятии изменения.
Ошибки и риски, которых стоит избегать
Попытка ввести жёсткие size-limits без переходного периода. Начните с мягких предупреждений, отслеживайте статистику размеров PR в течение месяца, вовлекайте команду в выработку нормы [11].
Размытое поле "почему именно так" в PR-темплейте. Если поле формальное и команда заполняет его шаблонными фразами — оно не работает. Нужны конкретные ожидания: минимум 2–3 предложения, объясняющие выбор подхода, а не его описание.
Доверие к AI-описанию PR как к истине. Исследование об inconsistency в Agentic-PR [14] показывает: автоматически сгенерированные описания могут не соответствовать фактическим изменениям. Рецензент должен сверять описание с диффом, а не читать только описание.
Игнорирование конфигов, миграций и CI/CD файлов. Именно эти категории читаются хуже всего при крупных PR — и именно в них часто сосредоточен реальный риск: неверные IAM-права, debug-флаги, слишком широкий CORS, секреты в environment variables.
Отсутствие метрик. Без отслеживания среднего размера PR, времени ревью и частоты post-merge дефектов невозможно оценить, работают ли введённые практики.
Кейс: почему даже функциональный PR не обязательно безопасен
Рассмотрим типичный сценарий. Разработчик использует AI-агент для реализации нового endpoint. Агент пишет 600 строк за 10 минут. Описание PR сгенерировано автоматически, выглядит связно. Рецензент видит большой diff, тесты прошли, описание разумное — и апрувает.
Что в этом PR может пойти не так:
- Вновь добавленная зависимость — галлюцинированный пакет, которого нет в официальном реестре, или пакет с известной уязвимостью.
- IAM-роль в конфиге настроена с избыточными правами — AI оптимизировал для того, чтобы «работало», а не для принципа минимальных привилегий.
- Входные данные не валидируются — стандартный CWE-89 или CWE-79, воспроизводимый из обучающих данных.
- Описание PR не соответствует реальным изменениям — агент описал намерение, а не то, что реально оказалось в diff.
При размере PR 600 строк рецензент с высокой вероятностью не дочитает diff до конца — именно это подтверждают данные Propel Code о падении defect detection rate [11]. Функционально PR работает. Безопасным для merge он не обязательно является.
Будущее: ревью как профессиональная дисциплина
DORA 2025 Report зафиксировал: при 90% AI-adoption в командах — «AI не чинит команду, он усиливает то, что уже есть» [2]. Если процесс ревью слабый, AI сделает его слабее быстрее.
Industria движется в сторону нескольких параллельных решений. Инструменты stacked PR (Graphite, приобретённый Cursor) помогают структурировать изменения до их открытия [22]. AI-ревьюеры (CodeRabbit, Qodo, Greptile) дают полезный первый слой проверки — но данные показывают, что их комментарии имеют смысл только при малых, сфокусированных PR [3, 23]. Инструменты SCA и SBOM помогают закрыть gap с зависимостями [6].
Но ни один из этих инструментов не решает проблему blind trust самостоятельно. Это культурный и процессный вопрос: рецензент должен получать PR, в котором он может разобраться; автор должен подтверждать, что он понимает изменение; зависимости должны проверяться явно.
Именно здесь дополнительный слой контроля до merge — такой, как HighVibe — становится не опцией, а необходимостью. Когда рабочий PR не обязательно безопасен, когда дифф дочитывают не до конца, когда новая зависимость приезжает незаметно — нужен инструмент, который анализирует конкретное изменение в контексте релиза и даёт короткий, понятный сигнал: можно ли безопасно принять именно это изменение сейчас. Не длинный отчёт. Не тотальное сканирование. Практический ответ для команды.
Что делать прямо сейчас
Начните с диагностики: какой средний размер PR в команде за последние 30 дней? Сколько PR за этот период превышали 400 строк? Есть ли PR-темплейт с обязательным полем «почему именно так»?
Если ответы неудовлетворительные — начните с одного изменения. Введите soft size-limit с предупреждением в CI. Добавьте в PR-темплейт одно обязательное поле: обоснование выбранного подхода. Через месяц оцените, изменились ли время ревью и количество post-merge дефектов.
AI-кодинг никуда не уйдёт. Но ревью — это тот шаг, который защищает команду от накопленного технического долга и инцидентов в production. Сделать его управляемым — задача инженерной культуры, а не только инструментов.
Источники
[1] Kusari — "AI Coding Assistants in 2026: 4× Faster, 10× Riskier" — https://www.kusari.dev/blog/ai-coding-assistants-in-2026-4x-faster-10x-riskier-the-hidden-security-cost
[2] philippdubach.com — "AI Coding Productivity Paradox: 93% Adoption, 10% Gains" — https://philippdubach.com/posts/93-of-developers-use-ai-coding-tools.-productivity-hasnt-moved./
[3] CodeRabbit — "State of AI vs Human Code Generation Report" — https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
[4] Kusari — "AI Coding Assistants in 2026: Veracode 45% OWASP vulnerabilities data" — https://www.kusari.dev/blog/ai-coding-assistants-in-2026-4x-faster-10x-riskier-the-hidden-security-cost
[5] arXiv — "Importing Phantoms: Measuring LLM Package Hallucination Vulnerabilities" — https://arxiv.org/pdf/2501.19012
[6] BleepingComputer — "AI-hallucinated code dependencies become new supply chain risk" — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/
[7] Sonar — "Sonar Data Reveals Critical 'Verification Gap' in AI Coding" — https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/
[8] Clutch — "Blind Trust in AI: Most Devs Use AI-Generated Code They Don't Understand" — https://clutch.co/resources/devs-use-ai-generated-code-they-dont-understand
[9] Codebridge — "The Hidden Costs of AI-Generated Code in 2026" — https://www.codebridge.tech/articles/the-hidden-costs-of-ai-generated-software-why-it-works-isnt-enough
[10] DeployHQ — "Pull Request Best Practices: A Complete Guide (2026)" — https://www.deployhq.com/blog/the-perfect-pull-request-best-practices-for-collaborative-development
[11] Propel Code — "The Impact of PR Size on Code Review Quality: What Data Tells Us" — https://www.propelcode.ai/blog/pr-size-impact-code-review-quality-data-study
[12] Google Engineering Practices — "Small CLs" — https://google.github.io/eng-practices/review/developer/small-cls.html
[13] Codebridge — "How to Ship Secure AI-Generated Code in 2026" — https://www.codebridge.tech/articles/how-to-ship-ai-generated-code-securely-a-governance-model-for-reviews-sandboxing-policies-and-ci-gates
[14] arXiv — "Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests" — https://arxiv.org/pdf/2601.04886
[15] MIT Technology Review — "AI coding is now everywhere. But not everyone is convinced." — https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/
[16] Stack Overflow Blog — "Mind the gap: Closing the AI trust gap for developers" — https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/
[17] EM Tools — "Pull Request Size: The Metric That Improves All Others" — https://www.em-tools.io/engineering-metrics/pull-request-size
[18] Microsoft Engineering Fundamentals Playbook — "Pull Requests" — https://microsoft.github.io/code-with-engineering-playbook/code-reviews/pull-requests/
[19] Codacy Blog — "Small Pull Requests: 6 reasons why they are the best choice" — https://blog.codacy.com/small-pull-requests
[20] Google Engineering Practices — "Writing good CL descriptions" — https://google.github.io/eng-practices/review/developer/cl-descriptions.html
[21] Google Engineering Practices — "What to look for in a code review" — https://google.github.io/eng-practices/review/reviewer/looking-for.html
[22] DEV Community — "The 6 Best AI Code Review Tools for Pull Requests in 2025" — https://dev.to/heraldofsolace/the-6-best-ai-code-review-tools-for-pull-requests-in-2025-4n43
[23] arXiv — "Does AI Code Review Lead to Code Changes? A Case Study of GitHub Actions" — https://arxiv.org/html/2508.18771v1