Vibe coding в DevOps: почему зеленый пайплайн — еще не победа

Вы просите Cursor или Claude разобраться, почему деплой в AWS падает на правах. Агент смотрит в логи, кивает, генерирует IAM Policy:

“Effect”: “Allow”

“Action”: “*”

“Resource”: “*”

Пайплайн зеленый. Вы счастливы. Секьюрити-инженер — нет.

Через полгода вы открываете репозиторий и находите там десять разных стандартов Helm-чартов, IAM-роли, розданные с правами “*”, и Terraform-стейт, который превратился в минное поле. Никто не принимал решение «давайте сделаем так» — оно сложилось само, из сотни маленьких «почини вот это сейчас». Вайб кодинг в инфраструктуре работает. Проблема в том, что платите вы не в момент, когда пишете промт, а через полгода, когда разгребаете последствия.

Ниже — три антипаттерна, которые мы видели вживую, и три уровня защиты, которые мы выстроили, чтобы агенты не превращали инфраструктуру в легаси за пару месяцев.

Что такое Vibe coding в Ops, и почему он реально дает х10

Вайб кодинг — это процесс, при котором вы описываете желаемое состояние инфраструктуры естественным языком, а AI-агент пишет IaC, скрипты и манифесты. Эволюция здесь короткая и честная:

• 2022: StackOverflow + Copy/Paste

• 2023: ChatGPT («напиши мне Bash-скрипт»)

• 2024: Copilot (автодополнение Terraform)

• 2025: Cursor / Claude / агенты («сделай рефакторинг модуля и обнови CI»)

В зеленой зоне AI действительно хорош. Генерация базовых Helm-чартов и K8s-манифестов, перевод CloudFormation в Terraform, перевод старого Ansible в свежий Terraform, написание regex и grep-однострочников, расшифровка километровых трейсов AWS IAM — все это агент делает быстрее и качественнее, чем человек, который в десятый раз копирует манифест из соседнего проекта.

Это чистое ускорение рутины, и отрицать его бессмысленно.

Проблема начинается там, где заканчивается boilerplate.

Красная зона: где все ломается

Агенты мыслят локально. Их задача — сделать так, чтобы код «завелся» прямо сейчас. Они не думают о дрейфе стейта, стоимости ресурсов и безопасности через год. Это не баг, это свойство. И именно оно порождает три антипаттерна, которые мы увидели.

— Security Driven by AI

AI всегда выбирает путь наименьшего сопротивления. Если пайплайн падает на правах — проще всего выдать права на все.

Мы ловили это не один раз. Запрос «почини деплой в AWS». Агент видит ошибку прав, генерирует политику с Action: “*”, Resource: “*”. Пайплайн зеленый, задача закрыта, инженер доволен. Секьюрити-инженер — нет.

Опасность здесь не в том, что агент ошибся. Он сделал ровно то, о чем его попросили: убрал препятствие. Опасность в том, что такое решение проходит ревью, потому что выглядит как обычный diff на пять строк. Никто не читает AIM Policy внимательно, если пайплайн зеленый.

— YAML Spaghetti и Copy-Paste Ops

Агенты не любят абстракции, если их явно не попросить. Попросите добавить новый сервис в K8s — и вместо переиспользования вашего корпоративного Helm-чарта получите 500 строк сырых Deployment, Dervice, Ingress и ConfigMap с хардкором внутри.

Это работает. Сервис поднимается. А через три месяца у вас в репозитории пять разных способов описывать одну и ту же сущность, и никто уже не помнит, какой из них «правильный». Классический инфраструктурный долг дублирования, только растет он в разы быстрее, потому что агент генерирует быстрее, чем вы успеваете ревьюить.

— Terraform State Ignorance

Самый болезненный. AI не понимает концепцию Terraform state и destruction ресурсов.

Сценарий: вы просите переименовать ресурс или изменить тип инстанса БД. Агент радостно переписывает HCL — с его точки зрения, это просто правка текста. Вы мержите PR, в CI применяется terraform plan, и он честно показывает Force Replacement: удаление базы и создание новой.

Итог — потерянные данные в проде. Не потому что агент какой-то не такой, а потому что для него Terraform state — это абстракция, которой нет в его модели мира. Он видит HCL как код, а не как декларацию состояния живой инфраструктуры.

Engeneering: выстраиваем guardrails

Если раньше IaC-линтеры были «nice to have», то с AI-агентами это вопрос выживания. Нам нужен инфраструктурный Harness — каркас безопасности из трех уровней.

Уровень 1: Контекст (промпты как инфраструктура)

Вы должны объяснить агенту ваши стандарты до того, как он начнет писать код. Файл правил (.cursorrules, AGENT.md) в репозитории с инфрой — это ваш новый корпоративный стандарт. И ревьюить его нужно так же строго, как изменения в Terraform.

У нас это выглядит примерно так: 

Markdown

# DevOps AI Rules

1. ВСЕГДА используй синтаксис Terraform >= 1.5.

2. НИКОГДА не используй Action: "*" в AWS IAM. Всегда применяй принцип least privilege.

3. Мы используем Terragrunt. Не пиши сырой Terraform в корневых директориях.

4. Для K8s всегда используй наш внутренний Helm-чарт из charts/core-svc.

5. Перед изменением ресурсов БД проверь, не вызовет ли это replace.

Это не «промптики». Это формализованное знание команды, которое раньше жило в головах тимлидов и в комментариях к старым PR.

Уровень 2: Policy as Code (автоматические инспекторы)

AI не должен обходить правила безопасности,. Здесь работают три обязательных инструмента в CI:

• Checkov / tfsec / Trivy — сканирование IaC на уязвимости. Именно они ловят те самые Action: "*" в IAM до мержа

• OPA (Open Policy Agent) / Conftest — проверка манифестов на корпоративные стандарты: обязательные labels, лимиты ресурсов, запрет определённых образов.

• Infrascost — защита от AI-галлюцинаций, которые развернут вам кластер на $10 000 в месяц. Потому что агент не чувствует стоимость, а вы — чувствуете.

Эти три штуки — не «на будущее». Это условие, при котором агента вообще можно пускать в IaC.

Уровень 3: Изменение процесса Code Review

Когда код пишет AI, ревьюить синтаксис бессмысленно — синтаксис агент знает лучше вас. Ревью смещается в другую плоскость. SRE смотрит на:

• Blast Radius: что еще сломается при деплое?

• State changes: внимательно читаем plan, нет ли удаления данных?

• Идемпотентность: сможет ли этот Ansible-скрипт запуститься дважды без ошибок?

Это другое ревью. Не «правильно ли написано», а «что произойдет с живой инфраструктурой, если это применить».

Что не сработало

Здесь хочется сказать, что после внедрения всех трех уровней все стало идеально, но увы

Правила в .cersorrules работают не всегда. Агент может их проигнорировать, если запрос сформулирован в обход, или если он уверен, что знает лучше. Мы до сих пор находим PR, где агент написал сырой Deployment вместо вызова нашего Helm-чарта — просто потому, что так было быстрее.

Policy-as-code реджектит много ложных срабатываний. На старте мы получали до трети PR, которые падали на OPA из-за формальностей, не связанных с безопасностью. Пришлось потратить время на тюнинг политик, и это не разовая задача.

Метрики пока неоднозанчные. Да Lead Time for Infrastructure упал, и заметно. Но Policy Violation Rate растет — не потому, что стало хуже, а потому, что мы стали это замечать. Это не победа, это просто другой уровень видимости. Считать это успехом пока рано.

Главное, что мы поняли — AI не отменяет инженерную дисциплину. Он ее обостряет. То, что раньше прощалось человеку, агент масштабирует до уровня системной проблемы за считанные месяцы.

А дальше?

Вайб кодинг дает х10 ускорение на рутине — YAML, скрипты, boilerplate, трансляции. Это факт, и отказываться от него глупо.

Но AI-агенты скрыто генерируют архитектурный и security-долг, выбирая простые решения. Это факт.

Роль DevOps в этой истории меняется: мы эволюционируем от «написания скриптов» к «построению пайплайнов, которые контролируют AI». Policy-as-code — пока единственный известный нам способ масштабировать AI-генерацию в инфраструктуре безопасно.

Полный разбор — с конкретными политиками, метриками после внедрения и тем, что у нас до сих пор не прижилось — покажу в ноябре на Centi Conf: DevOps Day. Там будет отдельный доклад со мной, архитектором Centicore Group. Если тема отзывается — приходите спорить.