Все сейчас радостно обсуждают AI-агентов которые могут писать код, чинить баги, открывать PR и ходить по репозиторию.

Я бы как DevOps/SRE в первую очередь смотрел куда у этого агента есть доступ.
Потому что рабочий repo это часто не просто папка с кодом.

Там рядом лежит .env.example, старый docker-compose.yml, .github/workflows/deploy.yml, какие-то bash-скрипты от 2021 года, Terraform, Helm charts, README где написано «для ручного деплоя выполнить вот это».

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

Теперь в этот же repo приходит агент.

Он не знает что staging у вас на самом деле ходит в боевую базу зачем-то.

Он не знает что secret с названием OLD_DEPLOY_TOKEN всё ещё работает.

Он не знает что backup_prod.sh лучше не запускать днём.

Он не знает что namespace test почему-то смотрит в реальные очереди.

Для людей это может быть устная договорённость в команде которая описана в лучшем случае где-то в confluence.

Для агента это просто файлы и команды которые логично что нужно применять на какой-то стадии CI/CD процесса.

Вот простой сценарий.

Агенту дали задачу:
«почини деплой, CI падает».

Он открывает .github/workflows/deploy.yml, видит что падает шаг с Docker registry при авторизации, находит рядом старый secret, меняет workflow, пушит PR что бы проверить помогло или нет.

Выглядит полезно и вроде бы логично.

Но если у него есть права запускать Actions с доступом к secrets, то вот внезапно он может окажатся рядом с продовой инфраструктурой.

Ещё хуже когда агенту дают не только repo, но и терминал.

Там начинается нормальная такая зона риска:

kubectl config current-context
aws sts get-caller-identity
terraform state pull
gh secret list
printenv

Все эти команды сами по себе обычные.

Но если агент может их выполнять, он может увидеть больше чем вы думали.

Я не против AI-агентов в DevOps.

Наоборот, для скучной рутины они могут быть очень полезны:
- разобрать лог;
- найти сломанный step в CI;
- проверить diff;
- собрать changelog;
- подготовить rollback-команду;
- сравнить values в Helm;
- найти где поменяли env.

Но давать агенту repo и терминал без ревизии доступов - это отчаяанная смелость, я как паранноик все по 500 раз перепроверю, куда оно может ходить и что делать.

Я бы перед этим проверял очень приземлённые вещи.

Есть ли .env в корне.

Есть ли .npmrc, .pypirc, docker login, старые ключи.

Какие GitHub Actions secrets доступны workflow.

Может ли агент пушить в main.

Может ли он запускать deploy job.

Есть ли kubeconfig на машине.

Куда указывает текущий kubectl context.

Есть ли Terraform state и что в нём лежит.

Можно ли из staging достучаться до prod-сервисов.

Пишутся ли действия агента в лог.

Есть ли нормальный rollback или только предположение «ну Вроде бы есть».

И только после этого уже обсуждать «насколько он ускоряет разработку».

Потому что если в инфраструктуре бардак, агент усиливает его, а не исправляет