Почему AI не справляется с инфраструктурой (и что с этим делать)

Все уже слышали: «Пусть нейросеть пишет код». И действительно, с логикой приложений она справляется неплохо. Маршруты, запросы к базе, утилиты — здесь модели показывают себя с лучшей стороны. Но есть область, где они почти всегда теряются.

Стоит дать модели Terraform-файл — и магия заканчивается.

Проблема контекста

Модели отлично знают синтаксис. Они напишут валидный HCL без ошибок. Проблема не в коде, а в том, почему приняты именно эти решения.

Допустим, вы просите добавить новое событие в систему сообщений. Нужен SNS-топик и очередь SQS. Модель создаст:

• топик SNS
• очередь SQS с dead-letter очередью
• подписку
• IAM-политики для сервиса-публикатора

Всё выглядит разумно. Но каждое число в конфигурации — случайный выбор. Видимость сообщения — 60 секунд или 600? Политика доступа к конкретному бакету или с wildcard? Срок хранения — 14 дней или дефолтное значение?

Модель берёт цифры из обучающих данных, не зная реальной нагрузки, привычек команды и прошлых инцидентов.

Ревью становится сложнее

Странным образом нагрузка на ревью не уменьшается, а растёт.

Проверять код приложения — это про логику и тесты. А ревью сгенерированной инфраструктуры превращается в кросс-проверку HCL, IAM, архитектуры пайплайнов и негласных договорённостей команды. Ревьюер вынужден держать в голове контекст, которого у AI нет. И когда что-то идёт не так, пейджер сработает у человека, а не у CI.

Причина — в разделении

Дело не в инструментах. Можно сколько угодно оборачивать AI в модули и валидаторы — корневая проблема останется.

Приложение и инфраструктура живут в разных репозиториях и проходят отдельные циклы ревью. AI принимает решения об инфраструктуре, не видя кода, который эту инфраструктуру будет использовать. Контекст просто отсутствует.

Другой подход: инфраструктура на этапе компиляции

А что, если инфраструктура перестанет быть отдельной задачей?

Представьте: вы описываете инфраструктуру прямо в типизированном коде приложения. Фреймворк сам создаёт ресурсы, настраивает IAM, очереди и подписки — исходя из того, что реально требуется коду.

Пример:

export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
  deliveryGuarantee: "at-least-once",
});

Никаких отдельных Terraform-файлов. Никаких ручных проверок политик. Фреймворк видит, как используется топик, и сам принимает решения. Опасные параметры уходят из зоны риска.

PR превращается в один diff на TypeScript, без пятидесяти строк HCL и ручной верификации.

Почему это важно для «вайб-кодинга»

Приложение можно безопасно отдавать AI, когда код типизирован и протестирован. Инфраструктура требует контекста, которого в изолированном файле нет.

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

Тогда инфраструктуру действительно можно кодить по наитию — и спать спокойно.