Принципи AI-driven інфраструктури

AI-агенти чудово генерують шаблонний код, розбирають логи та пояснюють legacy-код. Але інфраструктура — не звичайний код. У неї є стан, незворотність, каскадні залежності, слабкі зв’язки та секрети прямо в робочому потоці. Для LLM перейменування ресурсу й видалення бази — просто зміна рядків.

Мої принципи, можливо, не ідеальні, але це те, що склалося за півтора року роботи з агентами в інфраструктурі.

Підготовка середовища

1. Примусові обмеження

Агент не повинен вирішувати не ламати production — у нього не має бути можливості це зробити.

LLM нестабільно дотримуються заборон, особливо в довгих сесіях. Тому середовище агента має працювати з інфраструктурою лише в read-only. Мутуючі операції — тільки через окремий pipeline після явного підтвердження людиною.

2. Секрети поза контекстом агента

Контекстне вікно — потенційний канал витоку. State-файли OpenTofu/Terraform містять паролі, ключі та ендпоінти у відкритому вигляді. Helm values і Ansible group_vars часто містять облікові дані. Реальні атаки показали, що агенти за замовчуванням поводяться з приватними даними як з будь-якими іншими. Не роблячи для них винятків.

Методи захисту:

• Повна недоступність секретів
• Блокування доступу до файлів
• Відсутність згадок про файли та їх нестандартне розміщення
• Використання файлів-приманок

3. Верифікація джерел та ланцюга постачання

Агент використовує MCP-сервери, skills, сторонні модулі, community charts, розширення для IDE — кожен із них потенційний вектор атаки.

Правило: агент підключає лише явно дозволені джерела з фіксацією версій і lock-файлами. Новий MCP/skill/модуль/розширення додається лише після рев’ю команди.

Постановка задачі

4. Контекст = код + стан + рішення

LLM бачить файли конфігурації, але не знає, що реально зараз працює на серверах. Без контексту агент підставить “розумні значення за замовчуванням” із навчальних даних. Тому агент має отримувати дані з коду, від вас, із tofu plan, kubectl get, ansible-inventory, з описів залежностей, обмежень (бюджет, SLA, compliance) та причин рішень (ADR, SRS). Все, включно з тим, що “всі й так знають” — все має бути в контексті агента.

5. Делегуй лише те, що дешево перевірити

Агент завжди може помилитися — питання в тому, наскільки швидко й надійно ви це виявите.

Вартість перевірки складається з кількох критеріїв:

6. Явна ієрархія пріоритетів

Агент не “відчуває”, що таке втрата даних чи даунтайм. Вони для нього за замовчуванням менш важливі, ніж інструкції, а тим паче запит користувача.

Без ієрархії агент може, намагаючись оптимізувати швидкість або “чистоту” коду, знехтувати, наприклад, даними. Явний порядок в AGENTS.md:

1. Збереження даних та доступність сервісів
2. Безпека
3. Відповідність стандартам
4. Коректність реалізації
5. Швидкість та зручність

Кожен рівень не можна порушувати заради нижчого. Агент не видаляє й не перестворює RDS заради “чистоти” (зручність vs збереження даних). Не відкриває 0.0.0.0/0, щоб “запрацювало” (коректність vs безпека). Не ставить force_destroy = true на S3, щоб спростити код (зручність vs збереження даних).

На цей самий порядок мають бути налаштовані незалежні автоматичні рев’юери, які розглядатимуть правки як “чужий” код і не будуть схильні його “виправдовувати”.

Генерація коду

7. Маленькі кроки, часті контрольні точки

LLM деградують на довгих ланцюжках міркувань, а інфраструктурні зміни каскадні, там мало типізації й менш явні зв’язки, ніж у звичайному коді.

Одна ітерація = одна логічна зміна = один tofu plan / helm diff / ansible --check = один коміт. Не “мігруй VPC цілком”, а “додай subnet у новий AZ, покажи plan”. Кожна контрольна точка — місце, де людина може зупинитися й відкотити один коміт, а не весь рефакторинг.

Верифікація результату

8. Детерміністична верифікація замість довіри

LLM погано знаходять власні помилки — прохання “перевір” часто призводить до переконливого обґрунтування помилкової відповіді.

Результат агента перевіряється ланцюжком інструментів. Ключовий підсилювач — замкнутий цикл зворотного зв’язку: агент бачить вивід, виправляє помилку, повторює перевірку. Якість результату пропорційна якості зворотного зв’язку.

9. Автоматична оцінка зони ураження

AI не розуміє наслідків — для нього заміна instance type й видалення RDS рівнозначні. Тому зона ураження має обчислюватися автоматично з виводу інструментів: OPA/Sentinel policies на tofu plan, класифікація операцій (create/update/destroy), підрахунок зачеплених ресурсів та їхньої критичності.

Агент може підсвічувати неспівмірність зони ураження відносно розв’язуваної задачі, але не повинен навіть оцінювати ступінь, бо це розслаблює оператора.

10. Контроль вартості

AI-агент генерує “розумну” конфігурацію з навчальних даних, але не має уявлення про ваш бюджет.

GPU-інстанс замість CPU, NAT Gateway у кожному AZ, RDS із надмірними ресурсами — все це виглядає коректно в plan, проходить валідацію, але може коштувати в рази дорожче за необхідне.

Оцінка вартості (infracost, usage-based estimation) має бути частиною циклу зворотного зв’язку нарівні з tofu validate та plan. Агент бачить дельту вартості й зупиняється, якщо вона перевищує поріг.

Команда та процес

11. Протидія деградації навичок

AI-код виглядає професійно, проходить лінтери — і притуплює пильність.

Дослідження показують слабшу когнітивну залученість у користувачів AI-інструментів: гірше запам’ятовують, менше відчувають відповідальність. Команда, яка перестала розуміти свою інфраструктуру, не зможе самостійно відреагувати на інцидент у ситуації, коли агент недоступний або не може отримати повний контекст.

Контрзаходи: регулярні “ручні дні” без агента, ротація on-call з обов’язковим розбором інфраструктури, code review AI-коду з такою самою увагою, як до коду джуніора, періодичні навчання з реагування на інциденти без доступу до AI.

Усі принципи зводяться до однієї ідеї: AI-агент — потужний генератор, але не арбітр. Він пише код, а детерміністичні інструменти й люди вирішують, чи можна цей код застосовувати. Що дешевше перевірити результат — то більше можна делегувати.