AI-агенты в Terraform и Pulumi: что уже умеют, а что нет

За последний год инфраструктура как код обзавелась встроенными ассистентами: у Pulumi это Pulumi Copilot и режим Pulumi Neo, у HashiCorp — набор интеграций вокруг Terraform, включая помощь в генерации конфигураций и анализе плана. Плюс поверх этого работает целый слой универсальных агентов вроде GitHub Copilot и Claude Code, которые пишут HCL и TypeScript-инфраструктуру не хуже прикладного кода. Обещание везде одно: опишите словами, что нужно, а агент соберёт манифесты, посчитает plan и подскажет, что сломается. На практике разница между "сгенерировал YAML" и "развернул это в проде без инцидента" по-прежнему огромна.

Что именно появилось

Речь идёт о трёх пересекающихся сущностях, которые легко перепутать.

• Ассистенты внутри платформы IaC. Pulumi Copilot встроен в облачную консоль Pulumi Cloud и умеет отвечать на вопросы о ваших стеках, ресурсах и дрейфе состояния. Pulumi Neo подаётся как агент, который может выполнять многошаговые операции над инфраструктурой, а не только советовать.
• AI в экосистеме Terraform. HashiCorp (в 2024 году компанию согласилась купить IBM) развивает интеграции для генерации и объяснения конфигураций, а также использует ИИ в анализе кода и модулей. Terraform Registry и язык HCL при этом остаются прежними — меняется слой помощи вокруг них.
• Универсальные кодовые агенты. Claude Code, GitHub Copilot, Cursor и подобные не знают про IaC ничего специального, но отлично пишут HCL, Pulumi на TypeScript/Python/Go и умеют запускать команды в терминале, читая вывод terraform plan.

Почему это вообще работает

IaC — это текст с предсказуемой структурой и жёсткой обратной связью. У языка есть валидатор, у провайдера — схема ресурсов, у команды plan — точный список изменений до применения. Агенту не нужно угадывать, правилен ли результат: он запускает terraform validate и terraform plan, читает ошибку, правит и повторяет. Этот цикл "сгенерировал — проверил — исправил" даёт куда более надёжный результат, чем генерация прикладного кода без тестов.

Где агенты реально экономят время

Самые честные сценарии — рутина, где ошибка дешёва и заметна сразу.

• Черновик модуля с нуля. "Сделай VPC с тремя приватными и тремя публичными подсетями в трёх зонах доступности" — агент выдаёт рабочий скелет за минуту вместо получаса копирования из примеров.
• Перевод между инструментами. Переписать Terraform-модуль на Pulumi или наоборот, сохранив логику, — задача механическая и агенту даётся хорошо.
• Объяснение чужого кода. Разобраться, что делает унаследованный модуль на 800 строк HCL, быстрее через диалог, чем читая его подряд.
• Разбор ошибок plan и apply. Агент, видящий вывод команды, часто сразу указывает на циклическую зависимость или неверный тип аргумента.

Агент в IaC полезен ровно настолько, насколько силён ваш контур проверки. Без code review, plan-гейта в CI и отдельного стейта для тестов он просто быстрее генерирует то, что вы не успеваете проверить.

Где начинаются проблемы

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

• Устаревшие аргументы провайдера. Модель обучена на снапшоте данных и охотно предлагает поля, которые провайдер AWS или Google уже переименовал или удалил. plan это ловит, но только если вы его смотрите.
• Опасные операции под видом безобидных. Смена некоторых аргументов вызывает ForceNew — пересоздание ресурса. Для базы данных или диска это потеря данных. Агент не всегда предупреждает, что за строчкой в diff стоит destroy.
• Права доступа по принципу "чтобы заработало". Просьба "дай доступ к бакету" нередко превращается в политику с * в действиях. Функционально верно, для безопасности — беда.
• Уверенные выдумки. На вопрос о несуществующем ресурсе или модуле агент может собрать правдоподобный, но фиктивный код. Проверяется только запуском.

Сравнение подходов

Точные возможности и цены меняются часто — сверяйте на официальных страницах продуктов перед выбором.

Кому это пригодится, а кому нет

Пригодится:

• Командам, у которых уже настроен CI с обязательным plan и ручным подтверждением apply — здесь агент ускоряет черновики без риска.
• Инженерам, которые пишут много однотипных модулей: сети, IAM-роли, кластеры одного шаблона.
• Тем, кто наследует чужую инфраструктуру и тратит дни на её понимание.

Не пригодится или опасно:

• Проектам без изолированного стейта и без code review — агент лишь ускорит распространение ошибок.
• Стекам с ресурсами, где пересоздание = потеря данных, при доступе агента к apply без человека в цикле.
• Строгим комплаенс-контурам, где генерация кода моделью в облаке провайдера сама по себе может нарушать политику обработки данных.

Как подключать безопасно

1. Дайте агенту доступ к генерации и plan, но не к apply в проде. Применение оставьте человеку или CI-гейту.
2. Заведите отдельный стейт и тестовый аккаунт/проект облака для экспериментов агента.
3. Включите обязательный code review сгенерированного HCL — как для любого кода.
4. Настройте политики (например, OPA/Sentinel), которые блокируют опасные изменения независимо от того, кто их написал.
5. Читайте diff plan построчно, особенно строки с destroy и replace.

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