Код от ИИ-агентов: почему зелёный CI больше не гарантия безопасности

Зелёный CI больше не является доказательством безопасности. В мире ИИ-агентов прохождение CI — это лишь отражение способности агента убедить ваш пайплайн, что изменение безопасно, даже если оно немедленно деградирует инфраструктуру в масштабе. Сгенерированный агентом код опасно убедителен: он поставляется с отшлифованным описанием PR, проходит статический анализ, следует соглашениям репозитория и включает разумное покрытие тестами. На поверхности он выглядит так, будто написан опытным инженером. Но агент не понимает вашу производственную среду. Он не знает ваши паттерны трафика, ваши сценарии отказов или неявные ограничения вашей общей инфраструктуры. Он не знает, что экземпляр Redis близок к заполнению, что база данных жёстко привязана к конкретному региону или что rollout фича-флага фундаментально изменит профиль нагрузки downstream-системы. Разрыв между «этот PR выглядит корректным» и «этот PR безопасно отправлять» существовал всегда. Агенты расширяют этот разрыв, производя код, который выглядит более безупречным, чем когда-либо, оставаясь при этом полностью слепым к реалиям продакшна.

Почему зелёный CI больше не гарантирует безопасность

Кодинг-агенты генерируют код с беспрецедентной скоростью. В руках дисциплинированных инженеров они становятся мультипликатором продуктивности. Но без строгой оценки они — эффективный способ доставить неверные предположения прямо в продакшн. Vercel опубликовал внутренний доклад на эту тему, и проблема, которую он описывает, не уникальна для компании — фреймворк подходит любому, кто работает с агентами.

Когда команды развёртывают сгенерированный агентами код вслепую, последствия могут быть немедленными и серьёзными. Безупречный на вид пул-реквест может содержать запрос, который проходит тесты, но сканирует каждую строку в продакшне. Логика повторных попыток, кажущаяся корректной, может вызвать «табунный эффект» на downstream-сервисе. А кеш без TTL может незаметно расти, пока Redis не упадёт.

В чём разница между агентами и старыми инструментами?

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

Это особенно критично для платформ вроде Vercel, где развёртывание происходит часто и автоматически. Компания сама активно использует ИИ в своих продуктах (например, v0.dev), поэтому внутренний доклад — это не академическое упражнение, а практический опыт. Фреймворк, который они предлагают, основан на разграничении «полагаться на ИИ» и «использовать ИИ»: ставить свою подпись под PR означает «я прочитал и понял каждую строку», а не «я доверился агенту».

Как обеспечить безопасность при использовании ИИ-агентов

Vercel предлагает не отказываться от агентов, а внедрить жёсткие практики. Во-первых, каждый PR от агента должен проходить ручной код-ревью с особым вниманием к граничным случаям и побочным эффектам. Во-вторых, необходимо тестировать не только корректность, но и устойчивость к нагрузкам — зелёный CI не отменяет нагрузочного тестирования. В-третьих, использовать фича-флаги и канареечные развёртывания, чтобы ограничить радиус взрыва.

Ключевой принцип: агент не знает контекста вашей инфраструктуры. Поэтому любой сгенерированный код должен проверяться на знание production-окружения: не превышает ли он лимиты Redis, не вызывает ли каскадных запросов, не нарушает ли географическую привязку. Фреймворк Vercel включает чек-лист из трёх пунктов: «Понял ли я, что делает каждая строка?», «Учтены ли production-ограничения?», «Есть ли план отката?».

Какие риски несут ИИ-агенты для production?

Агенты генерируют код, который проходит статический анализ и юнит-тесты, но может быть катастрофическим под нагрузкой. Например, агент может написать запрос к БД, который в тестовой среде работает с сотней записей, а в продакшне сканирует миллионы. Или добавить retry-логику, которая при сбое сервиса создаст лавину повторных запросов. Или установить кеш без TTL, который приведёт к утечке памяти.

Проблема усугубляется тем, что агенты следуют шаблонам репозитория: они видят, как написаны другие функции, и копируют стиль. Если в коде есть антипаттерны, агент их воспроизведёт. Более того, агенты не понимают семантику бизнес-логики — они оптимизируют под формальные критерии (покрытие тестами, отсутствие ошибок линтера), а не под реальные требования.

Кого затронет и как адаптироваться

Разработчики и DevOps-инженеры — первая линия. Им придётся тратить больше времени на ревью, внедрять новые инструменты проверки и менять культуру. Для бизнеса риск в том, что быстрая поставка фич через агенты может обернуться инцидентами, которые сведут на нет выигрыш в скорости. Для платформ вроде Vercel, Netlify или AWS это означает необходимость адаптировать свои сервисы: возможно, добавлять пре-коммит-хуки, анализирующие production-контекст.

В российских и СНГ-командах ситуация аналогичная: многие уже используют Copilot и аналоги. Однако доступ к продвинутым агентам (например, Claude Code) может быть ограничен, что даёт время на подготовку. Тем не менее, общий тренд — рост автоматизации — требует пересмотра процессов.

Что будет дальше с безопасностью кода от ИИ

Vercel призывает к созданию инструментов, которые могли бы проверять код агентов на знание production-контекста. Возможно, появятся специализированные линтеры или анализаторы, которые будут моделировать поведение кода под нагрузкой. В ближайшее время стоит ожидать, что крупные платформы (GitHub, GitLab) внедрят дополнительные проверки для AI-генерированного кода. Сама Vercel, вероятно, интегрирует фреймворк в свой CI/CD, сделав его частью платформы.

Итог

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