Как оформлять PR, если большую часть кода написал AI: шаблон и правила атрибуции
Когда AI сгенерировал 80% изменения — кто подписывается под merge?
Почему оформление AI-PR — это отдельная дисциплина
AI-инструменты изменили соотношение скорости генерации кода и скорости его проверки. Cursor, GitHub Copilot, Claude Code — всё это позволяет одному разработчику выдавать объём кода, который раньше требовал дня работы. Но пропускная способность ревью не выросла с той же скоростью.
Исследование CodeRabbit декабря 2025 года на 470 опенсорсных проектах GitHub зафиксировало: AI-соавторский код содержит примерно в 1.7 раза больше серьёзных проблем по сравнению с человеческим [1]. Veracode в своём отчёте 2025 года протестировала более 100 LLM на четырёх языках и установила, что AI-генерированный код в 2.74 раза уязвимее человеческого, а показатель неудач на бенчмарках безопасного кодирования — 45% [2]. Apiiro в отдельном исследовании по Fortune 50 Enterprise зафиксировала рост путей к привилегированному escalation на 322%, рост ошибок дизайна на 153% и рост инцидентов с утечкой секретов на 40% [3].
Это не аргумент против AI-кодинга. Это аргумент за то, что PR с AI-кодом требует другого описания — такого, которое компенсирует информационный дефицит ревьюера.
В типичном PR ревьюер читает diff и может восстановить намерение автора. В AI-PR diff технически корректен, но за ним скрыто то, что не видно в строках: какую часть написал AI, насколько разработчик понял и перепроверил этот код, какие зависимости появились и почему, какие части несут повышенный риск.
Как отметила команда GitHub в своём материале "Code review in the age of AI", AI-ревьюеры хорошо работают с паттернами и поверхностными проверками, но архитектурные решения и бизнес-логику по-прежнему требуют человеческого надзора [4]. Та же логика применима к описанию PR: человек должен объяснить ревьюеру то, что инструмент не может объяснить за него.
Данные о том, что именно идёт не так в AI-PR
Прежде чем строить шаблон, важно понять, где конкретно возникают проблемы.
Первый класс рисков — логика и корректность. Исследование CodeRabbit зафиксировало, что readability-проблемы встречаются в AI-коавторских PR более чем в три раза чаще, formatting-проблемы — почти в три раза чаще, а проблемы с именованием — почти вдвое чаще по сравнению с человеческим кодом [1]. Это не косметика: когнитивная нагрузка при ревью растёт, что ведёт к пропуску реальных дефектов. Отдельно — null pointer и dereference-риски, которые следуют тому же паттерну роста.
Второй класс рисков — безопасность. Исследование Clacky AI декабря 2025 года фиксирует, что PR, созданные с участием AI, содержат в 1.57 раза больше security-проблем; AI-код в 2.74 раза чаще вводит XSS-уязвимости и в 1.91 раза чаще — небезопасные object references [5]. GitGuardian обнаружила, что репозитории, использующие Copilot, имеют на 40% более высокий процент утечки секретов по сравнению с репозиториями без AI-ассистирования [6].
Третий класс рисков — зависимости. Это наименее очевидный, но особенно опасный слой. Исследование 2025 года на USENIX Security Symposium, охватившее 576 000 сгенерированных Python- и JavaScript-примеров кода на 16 LLM, установило, что в среднем 19.6% рекомендованных пакетов не существовали [7]. Для коммерческих моделей (ChatGPT-4 и аналоги) показатель составил около 5%, для опенсорсных — порядка 21%. Эта угроза получила название slopsquatting: атакующий регистрирует пакет с именем, которое AI регулярно галлюцинирует, и ждёт, пока разработчик выполнит install [8].
Показательный случай: исследователь Чарли Эриксен в январе 2025 года зарегистрировал npm-пакет react-codeshift, ранее галлюцинированный LLM, и обнаружил его скачивание — пакет уже успел попасть в 237 GitHub-репозиториев [9]. Реальный вектор атаки был в шаге от реализации.
Четвёртый класс рисков — архитектурные изменения, не видимые в SAST. Endor Labs приводит примеры: разработчик добавил API-endpoint без аутентификации (функционально правильный код, критическая архитектурная уязвимость по CWE-306), или удалил state-параметр из OAuth 2.0 flow, молча сломав CSRF-защиту [10]. Обе проблемы не обнаруживаются SAST, потому что нет нарушения правила — есть нарушение архитектурного контракта. Именно поэтому PR-описание критически важно: только автор знает, что AI сделал архитектурный выбор, который мог быть неверным.
Почему разработчики не читают AI-код достаточно внимательно
Есть задокументированный психологический эффект: разработчики чувствуют меньшую ответственность за AI-генерированный код и тратят меньше времени на его проверку [2]. Код выглядит структурированным, он компилируется, тесты зелёные — это создаёт ложную уверенность в его корректности и безопасности.
Исследование команды из GitHub установило, что 28.3% AI-генерированных PR получают мгновенный merge без итеративного ревью [4]. Это нормально для узкой автоматизации, но критично, если AI менял что-то в логике аутентификации, настройках CORS, конфигах или миграциях.
Хорошо написанное PR-описание напрямую решает эту проблему: оно заставляет ревьюера остановиться на конкретных участках, а автора — сформулировать, что именно он проверил лично.
Команда Medium-блога о smarter pull requests зафиксировала, что после внедрения структурированных шаблонов и AI-гейтов "ревьюеры чувствовали меньше усталости — бот берёт на себя рутинные проверки, люди делают интересную работу" [11].
Шаблон PR-описания для AI-ассистированного изменения
Ниже — готовый шаблон, который можно положить в .github/pull_request_template.md. Он решает четыре задачи: атрибуция AI-вклада, документация человеческой проверки, прозрачность зависимостей, явный указатель на риски.
## Что изменилось
<!-- Краткое описание цели изменения: одно-два предложения. -->
---
## Участие AI в этом PR
<!-- Обязательный раздел для любого PR с AI-ассистированием. -->
**Инструмент(ы):** <!-- GitHub Copilot / Cursor / Claude Code / ChatGPT / другое -->
**Уровень AI-участия:**
- [ ] AI предложил отдельные строки / автодополнение — базовое ассистирование
- [ ] AI сгенерировал функции / методы, которые я адаптировал
- [ ] AI сгенерировал значительные блоки, я провёл ревью и правки
- [ ] AI сгенерировал большую часть изменения — ниже укажу, что именно перепроверил
**Что именно сгенерировал AI:**
<!-- Перечислите конкретные файлы, функции или блоки, которые написал AI.
Пример: "Вся логика в src/services/payment.ts — AI предложил полностью,
я проверил обработку ошибок и добавил валидацию входных данных." -->
---
## Что разработчик перепроверил вручную
<!-- Здесь фиксируется человеческая ответственность.
Опишите, что именно вы проверяли — не инструменты, а ваши наблюдения. -->
- [ ] Логика корректна и соответствует задаче
- [ ] Аутентификация и авторизация не нарушены новым кодом
- [ ] Обработка ошибок адекватна — нет silent failures
- [ ] Входные данные валидируются согласно стандартам проекта
- [ ] Нет захардкоженных секретов, токенов, паролей
- [ ] Нет отладочного кода, dev-флагов, console.log / print в production-путях
- [ ] CORS, заголовки безопасности, SSL-конфиги не изменены незаметно
**Дополнительные комментарии по проверке:**
<!-- Что именно показалось вам неочевидным в AI-генерированном коде и как вы это разрешили. -->
---
## Новые зависимости
<!-- Заполняйте, даже если кажется, что изменение невелико.
AI может добавлять зависимости неочевидно — в конфигах, через import. -->
| Пакет | Версия | Зачем добавлен | Проверен в реестре | CVE-скан |
|-------|--------|----------------|-------------------|----------|
| Нет новых зависимостей | — | — | — | — |
**Если были добавлены зависимости:**
- [ ] Пакет существует в официальном реестре (npm / PyPI / crates.io и т.д.) — проверено вручную
- [ ] Пакет не является опечаткой или вариацией известного имени (slopsquatting-риск)
- [ ] Версия зафиксирована в lock-файле
- [ ] Проведён SCA-скан на известные CVE
- [ ] Транзитивные зависимости проверены или допустимы по политике проекта
- [ ] Лицензия совместима с лицензией проекта
---
## Что рискованно в этом изменении
<!-- Критически важный раздел. Честный ответ здесь — основа доверия команды.
Если вы не уверены в безопасности участка — напишите об этом здесь,
а не молчите в надежде, что пройдёт. -->
**Уровень риска:** <!-- Низкий / Средний / Высокий -->
**Зоны повышенного внимания для ревьюера:**
<!-- Пример: "В функции processPayment (строки 47-82) AI использовал паттерн,
который я не встречал раньше. Функционально работает, но прошу посмотреть
отдельно на обработку граничных случаев." -->
**Затронутые чувствительные области:**
- [ ] Аутентификация / авторизация
- [ ] Платёжный процессинг / финансовые данные
- [ ] Персональные данные пользователей
- [ ] Конфигурационные файлы / переменные окружения
- [ ] Миграции базы данных
- [ ] CI/CD-конфиги / Dockerfile / скрипты деплоя
- [ ] Internal tools / admin-функционал
---
## Тестирование
- [ ] Unit-тесты покрывают новую логику
- [ ] Интеграционные тесты прошли
- [ ] Ручное тестирование пограничных случаев проведено
- [ ] Тесты написаны самостоятельно (не только AI-генерированные)
---
## Связанные задачи / контекст
<!-- Ссылки на тикеты, design docs, обсуждения в Slack. -->
---
## Чеклист для ревьюера
<!-- Рекомендации для ревьюера, исходя из особенностей этого PR -->
- [ ] Обратить особое внимание на секции, помеченные как рискованные
- [ ] Проверить логику в AI-генерированных блоках независимо от тестов
- [ ] Убедиться, что новые зависимости прошли SCA-сканКак работать с шаблоном: практические принципы
Атрибуция — не бюрократия, а защита команды
Явное указание "этот блок написал AI" решает несколько практических задач одновременно.
Ревьюер знает, куда смотреть внимательнее. AI-генерированный блок может быть синтаксически безупречен, но содержать архитектурное решение, которое не соответствует контексту проекта. Без атрибуции ревьюер читает код с одинаковым уровнем доверия.
Автор дисциплинируется сам. Необходимость написать "AI сгенерировал authentication middleware целиком" заставляет остановиться и ответить себе: а я действительно понял, как это работает?
Формируется аудит-трейл. В регулируемых индустриях — fintech, healthtech, enterprise — прозрачность о происхождении кода становится частью compliance-требований. GitHub уже исследует AI-assisted PR в контексте PCI-DSS и separation of duties [12].
Раздел человеческой проверки — это не галочки, а декларация
Разница между пустым чеклистом и заполненным значима. Команда видит, что автор не просто поставил галочки, но и добавил текстовый комментарий — что именно показалось неочевидным, что он изменил по сравнению с AI-предложением.
Это работает как cognitive forcing function: описание заставляет сформулировать, что вы реально проверили. Если в процессе написания ловите себя на том, что не можете честно заполнить строку — это сигнал вернуться к коду.
Секция зависимостей — обязательна, даже если кажется пустой
Тренд 2025–2026 годов: атаки на supply chain через AI-hallucinated packages. Исследование на USENIX Security 2025 задокументировало, что 43% галлюцинированных имён пакетов повторяются при схожих промптах — то есть они предсказуемы и становятся мишенями для slopsquatting-атак [7].
Практическое правило: любое имя пакета, предложенное AI, проверяется в официальном реестре вручную — не через поиск, а через прямой переход на страницу пакета. Проверяется дата создания (подозрительно: новый пакет с "нужным" именем), количество скачиваний, наличие реальной документации и репозитория.
Организации, использующие внутренние зеркала реестров (Nexus, Artifactory, pkg.dev), имеют дополнительный слой защиты: AI может предложить пакет, которого нет в зеркале, и install сразу упадёт с ошибкой. Это стоит настроить.
Секция рисков — честность важнее имиджа
Разработчики склонны недооценивать или скрывать риски, чтобы PR приняли быстро. Это создаёт долг, который проявляется в production.
Правило простое: если при написании PR-описания вы думаете "не уверен, правильно ли AI сделал X" — это идёт в раздел рисков. Если вы думаете "надо бы проверить, но некогда" — это тоже идёт в раздел рисков, с пометкой "прошу ревьюера уделить внимание".
Инцидент марта 2025 года: стартап Enrichlead прекратил работу после взлома, при котором атакующие обошли paywall через отсутствие логики аутентификации в AI-генерированном коде. Уязвимость была в продакшене — authentication logic не была проверена при merge [5].
Зоны особого риска: что AI делает хуже всего
Есть участки, которые требуют обязательной ручной проверки независимо от уровня доверия к инструменту.
Первая зона — аутентификация и авторизация. AI оптимизирует за functional correctness, а не за security correctness. Он может написать endpoint, который работает, но не проверяет права. Может убрать middleware-проверку как "избыточную". Может не реализовать rate limiting. Ни один из этих паттернов не является явным нарушением правила — SAST их не поймает [10].
Вторая зона — конфиги, .env, Dockerfile, CI/CD-файлы. Исследования фиксируют, что служебные файлы читаются ревьюерами хуже кода [11]. AI при этом может менять CORS-политику, добавлять debug-флаги, изменять переменные окружения или вносить изменения в pipeline, которые выглядят невинно, но открывают вектор атаки. GitGuardian зафиксировала на 40% более высокий процент утечки секретов в репозиториях с AI-ассистированием [6].
Третья зона — миграции баз данных. Необратимые операции. AI может написать миграцию, которая работает в dev, но ведёт к потере данных в production из-за разницы в объёме или наличии внешних ключей. Каждая миграция, написанная AI, проверяется на rollback-стратегию.
Четвёртая зона — криптография и генерация случайных чисел. AI воспроизводит распространённые паттерны из обучающего корпуса — включая небезопасные. Пример 2024 года: CVE-2024-21495 в библиотеке caddy-security — уязвимость из-за использования math/rand вместо crypto/rand для генерации nonce [13].
Пятая зона — внешние интеграции и API. AI может добавить вызов внешнего сервиса с широкими правами, не реализовав проверку ответа, или сохранить API-ключ в открытом виде "для удобства тестирования".
Инструментальный слой рядом с шаблоном
PR-шаблон работает в связке с автоматизацией, а не вместо неё.
На уровне CI целесообразно настроить: SAST (SonarQube, Checkmarx, Semgrep) с фокусом на изменённые функции; SCA (Snyk, OWASP Dependency-Check, Endor Labs) для проверки зависимостей на CVE; secret scanning (Trufflehog, GitGuardian); проверку lock-файлов на изменения.
AI-ревьюеры (CodeRabbit, Graphite Diamond, GitHub Copilot for PRs) полезны как первый проход — они ловят readability-проблемы, простые уязвимости и несоответствия стилю. Graphite фиксирует 67% rate внедрения AI-предложений по результатам ревью [14]. Но автоматизированные ревьюеры не заменяют человека на архитектурных и security-решениях.
Именно здесь полезен HighVibe как дополнительный слой контроля: инструмент анализирует конкретное изменение в контексте — код, конфиги, зависимости, релизный контекст — и даёт короткий сигнал о том, что требует внимания до merge. Это не замена SAST/SCA и не дублирование CI-проверок, а возможность поймать то, что лежит между правилами: архитектурный риск, подозрительную зависимость, изменение в служебном файле, которое прошло мимо автоматики.
Процесс: как изменить workflow команды
Внедрение шаблона без изменения культуры ревью малоэффективно. Несколько практических шагов.
Первое: договориться о минимальном "уровне честности". Галочки без комментариев хуже, чем вдумчивое описание трёх пунктов. Лучше меньше чеклиста, но заполненного реально.
Второе: ввести правило для AI-PR с высоким уровнем участия — обязательное ревью от конкретного человека, а не любого доступного ревьюера. AI-генерированная аутентификация должна смотреть кто-то с security-экспертизой.
Третье: отдельно закрепить, что проверка зависимостей — обязательный шаг, не опциональный. Перед merge: lock-файл изменился → SCA-скан прошёл → имена пакетов верифицированы вручную.
Четвёртое: разделить "функционально работает" и "безопасно принять в main". Это разные вопросы. Тест зелёный не означает, что архитектурное решение AI корректно. Исследование 2024 года зафиксировало: 67% критических инцидентов в production были change-related [15].
Пятое: разграничить типы кода по уровню доверия к AI. Практика 2025 года — явно указывать в политике команды зоны, где AI-генерация запрещена или требует усиленного ревью: authentication systems, cryptographic implementations, payment processing, secrets management [2].
Чего не нужно делать: типичные ошибки
Первая ошибка — использовать AI-сгенерированное описание PR как основу для шаблона. AI напишет Summary, который технически точен, но скроет риски. Описание должно писать люди.
Вторая ошибка — воспринимать чеклист как формальность. Если команда замечает, что все PR приходят с одинаковыми набором галочек — шаблон превратился в ритуал. Нужен регулярный ретроспективный разбор: что шаблон помог поймать, что прошло мимо.
Третья ошибка — игнорировать транзитивные зависимости. AI добавляет пакет A, который тянет пакет B с критической CVE. SCA должен работать именно на этом уровне.
Четвёртая ошибка — считать, что AI-PR требует меньше времени ревьюера. Данные говорят обратное: AI-PR в среднем содержат больше проблем и требуют более внимательного прочтения [1]. Шаблон помогает сфокусировать это время, но не сократить его.
Пятая ошибка — не документировать решения, с которыми разработчик не согласился. Если AI предложил подход, вы его отклонили и сделали иначе — это стоит зафиксировать в PR. Это помогает команде понять контекст и избежать повторения той же дискуссии.
Регуляторный контекст: почему это станет требованием
CISA и NSA в совместном руководстве "Deploying AI Systems Securely" (апрель 2024) указали: при использовании AI в разработке необходимо обеспечить confidentiality, integrity, и availability AI-output, а также адекватные меры на известные уязвимости [16]. В мае 2025 вышло расширенное руководство по AI data security, охватывающее supply chain risks и data integrity [17].
GitHub в 2023 году исследовал применение AI-PR в контексте PCI-DSS: AI как объективный ревьюер создаёт "separation of duties", которая ранее требовала двух разных людей [12]. Это означает, что аудиторы уже смотрят на AI-PR как на объект compliance-проверки.
Для команд в финансовом секторе, здравоохранении и enterprise с аудитом: шаблон с явной атрибуцией AI-участия — это начало аудит-трейла, который может потребоваться при инциденте или проверке.
Заключение: PR-описание как акт профессиональной ответственности
AI ускорил разработку. Контроль качества не ускорился с той же скоростью. Разрыв покрывается людьми — и PR-описание один из главных инструментов этого покрытия.
Хорошо написанный PR с явной атрибуцией AI-участия, честной документацией проверки и прозрачными зависимостями — это не бюрократия. Это профессиональный стандарт, который защищает команду, продукт и пользователей.
Ответственность за merge остаётся с разработчиком. Шаблон помогает эту ответственность выполнить.
Источники
[1] Help Net Security — "AI code looks fine until the review starts" — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/
[2] 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/
[3] Checkmarx Blog — "2025 CISO Guide to Securing AI-Generated Code" — https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/
[4] Skywork AI — "Enhanced Code Review Agent: GitHub's AI-Powered PR Review System" — https://skywork.ai/blog/agent/enhanced-code-review-agent-githubs-ai-powered-pr-review-system/
[5] ClackyAI Blog — "Code Review Checklist for AI-Generated Code" — https://clacky.ai/blog/code-review-checklist-ai-generated-code
[6] 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
[7] USENIX — "Package Hallucinations: How LLMs Can Invent Vulnerabilities" — https://www.usenix.org/publications/loginonline/we-have-package-you-comprehensive-analysis-package-hallucinations-code
[8] FOSSA Blog — "Slopsquatting: AI Hallucinations and the New Software Supply Chain Risk" — https://fossa.com/blog/slopsquatting-ai-hallucinations-new-software-supply-chain-risk/
[9] InfoWorld — "Supply-chain attacks take aim at your AI coding agents" — https://www.infoworld.com/article/4167479/supply-chain-attacks-take-aim-at-your-ai-coding-agents-2.html
[10] Endor Labs — "Introducing AI Security Code Review" — https://www.endorlabs.com/learn/introducing-ai-security-code-review
[11] Medium / Rethink Your Understanding — "Smarter Pull Requests: Balancing AI, Automation, and Human Review" — https://medium.com/@rethinkyourunderstanding/smarter-pull-requests-balancing-ai-automation-and-human-review-ebb7d586e968
[12] ZenML LLMOps Database — "GitHub: AI-Powered Code Review and Pull Request Automation for Developer Compliance" — https://www.zenml.io/llmops-database/ai-powered-code-review-and-pull-request-automation-for-developer-compliance
[13] CodeAnt AI — "Secure Code Audits in 2025: Checklist and Best Practices" — https://www.codeant.ai/blogs/source-code-audit-checklist-best-practices-for-secure-code
[14] Graphite — "AI-generated pull request descriptions: benefits and best practices" — https://graphite.com/guides/ai-generated-pr-descriptions
[15] Knostic AI — "How to Secure AI Coding Assistants and Protect Your Codebase" — https://www.knostic.ai/blog/ai-coding-assistant-security
[16] CISA — "Joint Guidance on Deploying AI Systems Securely" — https://www.cisa.gov/news-events/alerts/2024/04/15/joint-guidance-deploying-ai-systems-securely
[17] Alston & Bird — "NSA, CISA, FBI Joint International Guidance on AI Data Security" — https://www.alston.com/en/insights/publications/2025/06/joint-guidance-ai-data-security