Почему обычное ревью кода не спасает от рисков ИИ-разработки

Кажется, что PR прочитан. На самом деле — нет

Скорость выросла, контроль — нет

С 2024 года ИИ-ассистенты стали полноправной частью большинства производственных пайплайнов. По данным Checkmarx, почти 70% респондентов — CISOs, менеджеры AppSec и разработчики — оценивают долю AI-generated кода в своих организациях выше 40%; 44,4% называют диапазон 41–60% [1]. Stack Overflow Developer Survey 2024 фиксирует похожую картину: 76% разработчиков используют ИИ-инструменты в повседневной работе [1].

Ускорение реальное. PR-ы закрываются быстрее, фичи выходят раньше. Но при этом публичные коммиты на GitHub в 2025 году выросли на 43% год к году — темп минимум вдвое выше предыдущих лет [2]. Объём кода, который нужно проверить, вырос кратно. Количество ревьюеров и часов в сутках — нет.

Именно здесь возникает системный разрыв: привычное code review, разработанное под иной темп и иной объём, не справляется с новой реальностью. Не потому что разработчики стали хуже. А потому что задача принципиально изменилась.

Что происходит с качеством ИИ-кода

Прежде чем говорить о ревью, нужно понять, с чем именно оно работает.

Исследование CodeRabbit, проанализировавшее 470 GitHub PR в декабре 2025 года, показало: AI-assisted pull request в среднем содержит 10,83 проблемы против 6,45 у человеческого — разница в 1,7 раза [3]. Но важнее не количество, а структура: логические ошибки растут на 75%, security-уязвимости — в 1,5–2 раза; среди них чаще всего встречаются некорректная обработка паролей и небезопасные объектные ссылки [4].

Veracode в 2025 году провела тестирование более 100 языковых моделей по 80 задачам на четырёх языках программирования — и получила результат: лишь 55% сгенерированного кода оказалось безопасным [5]. Checkmarx отдельно выяснял, что 29,5% Python-сниппетов и 24,2% JavaScript-сниппетов, созданных Copilot, содержат уязвимости, включая XSS и некорректную валидацию ввода [1].

Отдельно выделяется исследование, принятое в IEEE-ISTAS 2025: при итеративной генерации кода через LLM (пять итераций «улучшения») количество критических уязвимостей выросло на 37,6% [6]. То есть чем дольше ИИ «дорабатывает» код, тем хуже становится его security-профиль — причём разработчики и ревьюеры в этом процессе, как правило, не участвуют.

Независимое исследование Apiiro среди Fortune 50 компаний зафиксировало: уязвимости уровня CVSS 7.0+ встречаются в AI-generated коде в 2,5 раза чаще, чем в написанном людьми [7]. К июню 2025 года ИИ-код добавлял свыше 10 000 новых security-находок в месяц по отслеживаемым репозиториям — рост в 10 раз по сравнению с декабрём 2024-го [7].

При этом рецензенты не воспринимают ИИ-код как более проблемный. Академическое исследование 2025–2026 годов (Kyushu University, Nara Institute of Science and Technology и другие) зафиксировало обратное: ревьюеры реагировали на AI-generated PR с более нейтральными или позитивными эмоциями, чем на человеческий код [8]. Поверхностная корректность маскирует скрытые дефекты, накапливающийся технический долг «проходит» мимо комментариев.

Почему ревью не видит то, что нужно увидеть

Когнитивный потолок не изменился

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

Исследование паттернов ревью, опубликованное в 2025 году, показывает: при скорости около 450 строк в час 87% проверок пропускают дефекты [9]. Команды, которые наладили устойчивый процесс, сходятся на диапазоне 200–400 строк как оптимальном для одного ревью. Выше 600 строк — комментарии смещаются в сторону стилистики и очевидных опечаток; глубокое мышление прекращается [9].

ИИ-ассистенты увеличивают объём PR, не уменьшая его. Агент легко генерирует изменение на 800–1500 строк за один сеанс. Такой диф технически соответствует критериям merge — работает, тесты проходят, — но для человека это когнитивная стена.

Как точно описал один технический директор: «500-строчный AI-generated диф от агента в незнакомом сервисе — это уже не code review. Это его имитация» [10].

Социальная динамика давит в сторону «Approve»

Долго висящие PR создают давление на одобрение. Ревьюеры, которые часто поднимают проблемы, получают репутацию «тормозящих» разработку. Стимулы указывают в сторону «выглядит хорошо», а не «я нашёл что-то важное» [10].

Опрос Qodo 2025 года показывает: при включённых AI code review агентах 80% PR не получают ни одного человеческого комментария [11]. Это не говорит о том, что агенты хорошо справляются; это говорит о том, что люди перестают смотреть.

ИИ-код маскирует признаки проблем

Человеческий автор, написавший путаный PR, обычно оставляет следы: непоследовательные имена, брошенные комментарии, TODO вида «исправить это». ИИ убирает эти сигналы по умолчанию. Код выглядит аккуратно, форматирование идеально, переменные названы «правильно» — но имена при этом могут быть несогласованными с контекстом репозитория, а управляющий поток — потенциально небезопасным.

CodeRabbit зафиксировал: AI-generated изменения регулярно содержат рассогласованную терминологию, общие идентификаторы и стилистический дрейф в сторону дефолтных паттернов — что само по себе увеличивает когнитивную нагрузку на ревьюера [4].

Академическая работа 2025–2026 годов, исследовавшая 16 популярных AI code review actions для GitHub, показала: даже при наличии AI-ревьюера в пайплайне значительная часть комментариев не приводит к изменению кода — разрыв между «замечено» и «исправлено» устойчиво сохраняется [12].

Новые категории рисков, которые не ловит стандартное ревью

Слопсквоттинг и галлюцинированные зависимости

В апреле 2025 года был введён термин «slopsquatting» — атака, при которой злоумышленник регистрирует название пакета, которое LLM регулярно галлюцинирует в своих ответах [13]. Разработчик вставляет рекомендованную ИИ зависимость, не проверяя её существование — и устанавливает подготовленный атакующим вредоносный пакет.

Первый задокументированный эксперимент состоялся ещё в 2023 году: исследователь Bar Lanyado опубликовал пустой пакет под галлюцинированным LLM-именем «huggingface-cli» и за три месяца получил более 30 000 загрузок [13]. Пакет с тем же именем был упомянут в README исследовательского репозитория Alibaba.

В мае 2025 года академическая работа «We Have a Package for You!» детально задокументировала масштаб проблемы. Стандартное ревью не проверяет, существует ли пакет фактически и не является ли он malicious-клоном. Ревьюер видит знакомо выглядящее название и идёт дальше.

Утечки секретов в AI-assisted коммитах

GitGuardian в своём отчёте State of Secrets Sprawl 2026 (март 2026) зафиксировал 28,65 миллиона новых хардкодированных секретов в публичных коммитах GitHub за 2025 год — крупнейший прирост за всё время наблюдений, рост 34% год к году [14].

Коммиты с участием ИИ-ассистентов показали частоту утечек секретов 3,2% против 1,5% в среднем по всем публичным коммитам — то есть примерно вдвое выше базового уровня [14]. Учётные данные AI-сервисов (API-ключи LLM-провайдеров, платформ для эмбеддингов) выросли на 81% год к году, достигнув 1 275 105 зафиксированных утечек [14]. Только ключей DeepSeek в публичных репозиториях за 2025 год обнаружено более 113 000.

Отдельный вектор — конфигурационные файлы MCP (Model Context Protocol): GitGuardian нашёл 24 008 уникальных секретов в MCP-конфигах на публичном GitHub, из которых 2 117 остаются валидными [14]. Официальные quickstart-инструкции к MCP-серверам по умолчанию приводили примеры с учётными данными прямо в файлах.

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

Ещё один задокументированный случай: в 2024 году выяснилось, что Cursor (AI-редактор кода) передавал содержимое .env-файлов на свои серверы для функции автодополнения, даже если файлы были добавлены в .cursorignore [15].

Деградация безопасности при итерациях

Как показало исследование IEEE-ISTAS 2025, итеративное «улучшение» кода через LLM не делает его безопаснее [6]. Особенно контринтуитивный результат: в промптах, специально направленных на улучшение security, уязвимости появлялись с той же или большей вероятностью — модель «исправляла» одно, незаметно ломая другое.

Это означает, что паттерн «попрошу ИИ ещё раз поправить с учётом security» не является надёжной практикой без независимой проверки.

Конфиги, миграции и служебный код остаются в слепой зоне

CI/CD-файлы, Dockerfile, конфиги Kubernetes, SQL-миграции, скрипты деплоя — всё это пишется и переписывается ИИ-ассистентами всё чаще. Именно этот класс файлов читают хуже всего в процессе ревью: они «скучные», объёмные, синтаксически корректные.

Между тем именно здесь сосредоточены риски supply chain. В марте 2026 года несколько поддерживаемых Checkmarx GitHub Actions были скомпрометированы: злоумышленники внедрили malware, похищавший Cloud, GitHub и CI/CD-секреты из затронутых воркфлоу [16]. Вектор атаки — конфигурационный файл, не production-код.

Почему SAST/SCA недостаточно

Статические анализаторы и SCA-инструменты — необходимая часть AppSec-стека. Но они решают другую задачу.

SAST сканирует код на паттерны уязвимостей, известных в момент составления правил. Он не понимает контекст релиза: например, что конкретный PR включает не просто рефакторинг, а изменение auth-логики в критически важном микросервисе накануне выпуска. Он не оценивает, уместна ли новая транзитивная зависимость именно сейчас.

SCA показывает известные уязвимости в зависимостях — но не проверяет, существует ли зависимость в принципе (slopsquatting) и не является ли она подменой легитимного пакета.

Длинный security-отчёт перед релизом — ещё одна проблема. Команда получает список из 40 позиций разного приоритета. Времени мало. В результате — либо релиз блокируется из-за шума, либо критические пункты теряются среди low-priority замечаний.

Разрыв не в качестве инструментов. Разрыв — в отсутствии слоя, который анализирует конкретное изменение в его контексте и отвечает на практический вопрос: «Можно ли безопасно принять именно этот PR прямо сейчас?»

Именно этим занимается HighVibe: анализирует конкретные изменения в коде, конфигурации и служебных файлах, новые и обновлённые зависимости, контекст релиза — и даёт короткий, понятный сигнал команде до merge и выпуска. Не замена SAST/SCA/SBOM, а дополнительный слой между «работает» и «безопасно сливать».

Что конкретно нужно проверять в ИИ-сгенерированном PR

До того как открыть диф

1. Понять, сгенерирован ли этот PR с помощью ИИ-агента, и если да — каким образом (Copilot, агент с автономными итерациями, вибкодинг). Это меняет стратегию ревью.
2. Проверить размер PR: если он превышает 400–600 строк, требовать декомпозиции — когнитивный потолок не переговаривается.
3. Убедиться, что к PR приложено описание, объясняющее бизнес-логику. ИИ не оставляет контекста сам по себе.

В процессе ревью

1. Пройтись по всем новым и изменённым зависимостям: существуют ли они, актуальны ли версии, нет ли CVE, не является ли пакет подозрительным клоном существующего.
2. Проверить все конфигурационные файлы, включённые в PR: .env, docker-compose.yml, Kubernetes-манифесты, CI/CD-пайплайны, MCP-конфиги.
3. Поискать хардкодированные секреты — API-ключи, токены, пароли, строки подключения. ИИ регулярно вставляет примеры в seed-данные, тестовые фикстуры и конфиги.
4. Проверить auth-логику, валидацию ввода, обработку ошибок — именно здесь статистически больше всего security-дефектов в AI-generated коде.
5. Оценить, соответствует ли код реальной бизнес-логике системы, а не только задаче из промпта.

Перед merge

1. Убедиться, что изменение понятно относительно контекста релиза: не блокирует ли оно другие PR, не вносит ли несовместимых изменений, не требует ли миграций с downtime.
2. При любых изменениях в CI/CD-файлах — отдельная проверка на возможность supply chain атаки.

Типичные ошибки и как их избежать

Ошибка первая: «Тесты проходят — значит безопасно». Тесты проверяют функциональность, не security. ИИ-агенты умеют генерировать код, который проходит собственные же тесты при наличии уязвимостей.

Ошибка вторая: «Мы читаем каждый PR». Читаете ли вы каждый конфиг-файл в составе PR? Каждую транзитивную зависимость? Каждый lock-файл?

Ошибка третья: «Наш SAST всё поймает». Стандартный SAST не проверяет существование пакетов, не видит контекст релиза, не анализирует семантику изменения — только синтаксис.

Ошибка четвёртая: «Мы попросим ИИ ещё раз улучшить с учётом безопасности». Итеративные LLM-итерации в среднем ухудшают security-профиль кода, а не улучшают его [6].

Ошибка пятая: «Это внутренний инструмент / прототип, там меньше рисков». Именно internal tools и конфиги часто содержат самые чувствительные учётные данные и минимально проверяются.

Что показывает практика

Y Combinator сообщил, что в наборе Winter 2025 каждый четвёртый стартап имел кодовую базу, на 95% состоящую из AI-generated кода [17]. По данным Addy Osmani, к началу 2026 года более 30% senior-разработчиков сообщают, что отгружают преимущественно AI-generated код [18].

Это не плохо само по себе. Проблема в том, что в 80% случаев PR с включённым AI-ревьюером не получает ни одного человеческого комментария [11], а 64% секретов, обнаруженных ещё в 2022 году, к 2025-му всё ещё не были отозваны [14]. Команды видят утечку — и не реагируют.

Реальный сценарий, который стал публично известен: разработчик описал, как AI-агент «сошёл с ума во время code freeze» и удалил всю базу данных [4]. Это экстремальный случай, но он иллюстрирует главное: AI-агент не знает контекста релиза, не знает, что code freeze — это особый момент, и не несёт ответственности за последствия.

Практический decision framework

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

1. Маркировать AI-assisted коммиты: использовать co-authored-by или аналогичный механизм, чтобы понимать объём AI-кода в репозитории.
2. Ввести size gate на PR: автоматически блокировать PRs крупнее 400 строк без явного обоснования.
3. Запустить автоматическое сканирование секретов на уровне pre-commit и CI: gitleaks, truffleHog или коммерческие аналоги.
4. Добавить проверку зависимостей не только на CVE, но и на существование, репутацию и подлинность пакета.
5. Ввести обязательную проверку конфигурационных и CI/CD-файлов отдельно от code-ревью — с другим чеклистом.
6. Для security-критичных изменений (auth, платёжные потоки, обработка PD) — явный gate с участием AppSec/DevSecOps.
7. Перед каждым релизом — отдельный короткий сигнал: что в этом релизе может блокировать выпуск, а не полный отчёт.

Это минимальная конфигурация. HighVibe реализует её как слой контроля, встроенный в пайплайн: анализирует конкретное изменение — код, конфиги, зависимости, контекст — и даёт команде ответ в формате «можно слить / нужно проверить / стоп» до merge.

Тренды и куда движется ситуация

Объём AI-generated кода продолжит расти. GitHub отмечает, что в 2025 году публичные коммиты выросли на 43%, и рост не замедляется [2]. Доля ИИ-кода в командах будет увеличиваться независимо от решений отдельных CTO — потому что это инструмент конкурентного преимущества.

Параллельно атакующие адаптируются: slopsquatting как вектор уже задокументирован и эксплуатируется; MCP-конфиги как новая поверхность атаки уже зафиксированы в отчётах; supply chain-атаки через CI/CD-файлы становятся стандартным инструментарием.

Регуляторное давление тоже растёт. Немецкое BSI и французское ANSSI совместно выпустили руководство по безопасности AI coding assistants, прямо указывающее на риски и необходимость дополнительного контроля [19].

Ключевой вывод: «работает» и «безопасно сливать» — разные утверждения. Разрыв между ними будет только увеличиваться по мере роста автономности агентов.

Заключение

Обычное code review создавалось под другую задачу. Оно предполагает, что автор понимает, что написал; что объём изменений соразмерен человеческому восприятию; что зависимости реальны; что в конфигах нет секретов; что контекст релиза учтён.

Ни одно из этих допущений не работает в условиях массового AI-assisted кодинга.

Решение не в том, чтобы вернуться к ручному написанию кода или удвоить количество ревьюеров. Решение — в том, чтобы добавить слой контроля, который анализирует конкретное изменение в его контексте и отвечает на практический вопрос до merge: «Есть ли здесь что-то, что блокирует этот PR?»

ИИ ускоряет разработку. Контроль должен успевать с той же скоростью.

Источники

[1] Checkmarx — "2025 CISO Guide to Securing AI-Generated Code" — https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/

[2] SecurityBrief Asia — "AI surge drives record secrets sprawl across GitHub" — https://securitybrief.asia/story/ai-surge-drives-record-secrets-sprawl-across-github

[3] Help Net Security — "AI code looks fine until the review starts" — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/

[4] CodeRabbit / Business Wire — "State of AI vs Human Code Generation Report" — https://www.businesswire.com/news/home/20251217666881/en/CodeRabbits-State-of-AI-vs-Human-Code-Generation-Report-Finds-That-AI-Written-Code-Produces-1.7x-More-Issues-Than-Human-Code

[5] Veracode — "AI-Generated Code Security Risks: What Developers Must Know" — https://www.veracode.com/blog/ai-generated-code-security-risks/

[6] arXiv / IEEE-ISTAS 2025 — "Security Degradation in Iterative AI Code Generation" — https://arxiv.org/html/2506.11022v2

[7] SoftwareSeni — "AI-Generated Code Security Risks – Why Vulnerabilities Increase 2.74x" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[8] arXiv — "More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests" — https://arxiv.org/pdf/2601.21276

[9] Rishi Baldawa — "The Cognitive Load Cliff in Code Review" — https://rishi.baldawa.com/posts/pr-throughput/cognitive-load-cliff/

[10] Ikangai — "Human code review is dead" — https://www.ikangai.com/human-code-review-is-dead/

[11] Qodo — "State of AI Code Quality 2025" — https://www.qodo.ai/reports/state-of-ai-code-quality/

[12] arXiv — "Does AI Code Review Lead to Code Changes? A Case Study of GitHub Actions" — https://arxiv.org/html/2508.18771v1

[13] Wikipedia — "Slopsquatting" — https://en.wikipedia.org/wiki/Slopsquatting

[14] GitGuardian / Help Net Security — "29 million leaked secrets in 2025: Why AI agents credentials are out of control" — https://www.helpnetsecurity.com/2026/04/14/gitguardian-ai-agents-credentials-leak/

[15] Snyk — "Why 28 million credentials leaked on GitHub in 2025" — https://snyk.io/articles/state-of-secrets/

[16] Wikipedia — "Checkmarx" — https://en.wikipedia.org/wiki/Checkmarx

[17] Wikipedia — "Vibe coding" — https://en.wikipedia.org/wiki/Vibe_coding

[18] Addy Osmani — "Code Review in the Age of AI" — https://addyo.substack.com/p/code-review-in-the-age-of-ai

[19] Wikipedia — "AI-assisted software development" (ссылка на совместный документ BSI/ANSSI) — https://en.wikipedia.org/wiki/AI-assisted_software_development