Решил провести честный эксперимент, вместо того чтобы теоретизировать на тему того, насколько хорошо современные языковые модели справляются с написанием инфраструктурного кода. Взял несколько реальных, но не самых тривиальных задач из своей повседневной практики и попросил модель написать конфигурацию Terraform с нуля, а сам сел рядом в роли придирчивого ревьюера, каким обычно бываю для младших коллег. Первое, что бросилось в глаза, это скорость и уверенность, с которой модель выдает результат. Задача, на которую у не самого опытного инженера ушел бы час, а то и больше, включая чтение документации провайдера и подбор правильных названий атрибутов, была решена за считанные секунды, причем синтаксически безупречно. Структура модулей, разумное разделение переменных и выходных значений, аккуратные имена ресурсов, все это выглядело так, будто писал вполне компетентный middle специалист, знакомый с общепринятыми соглашениями по оформлению кода. Но чем внимательнее я вчитывался, тем больше находил деталей, которые заставили бы меня как ревьюера отправить код на доработку. Первая категория проблем это устаревшие или неоптимальные подходы, которые давно считаются плохой практикой, но продолжают массово встречаться в обучающих материалах и старой документации, откуда модель, судя по всему, черпает значительную часть своих знаний. Например, жестко прописанные значения там, где давно принято использовать параметризацию через переменные, или отсутствие явного управления состоянием блокировки, без которого параллельная работа нескольких инженеров с одной и той же инфраструктурой рано или поздно приведет к конфликту изменений. Вторая категория проблем куда более коварная, это тонкие несоответствия между тем, что код формально описывает, и тем, что реально нужно бизнесу в конкретном контексте. Модель прекрасно справляется с задачей в общем виде, но совершенно не знает про специфические ограничения именно вашей организации, про то, что определенный тип ресурса в вашей компании обязан создаваться только в одном конкретном регионе по требованиям комплаенса, или что определенная сетевая политика противоречит внутренним стандартам безопасности, принятым в компании три месяца назад после последнего аудита. Ни один универсальный инструмент, обученный на общедоступных данных, не способен знать эти локальные, специфичные именно для вашей организации детали, если явно их не указать в самом запросе. Третья, пожалуй, самая опасная категория, это уверенный и убедительный тон, с которым модель выдает результат, вне зависимости от того, насколько этот результат на самом деле корректен. В отличие от неопытного человека, который часто сам сомневается и явно помечает места, где не уверен в правильности решения, языковая модель обычно формулирует любой свой ответ с одинаковой уверенностью, что создает опасную иллюзию надежности там, где ее на самом деле может не быть. Именно поэтому я категорически не советую применять сгенерированный подобным образом инфраструктурный код к продакшену без полноценного ревью человеком, обладающим реальным опытом и пониманием специфики конкретной инфраструктуры. При этом я далек от того, чтобы полностью отвергать пользу подобных инструментов. Как черновик, как отправная точка, как способ быстро набросать структуру и напомнить синтаксис редко используемого блока конфигурации, инструмент показывает себя отлично и реально экономит время. Проблема возникает только тогда, когда команда начинает воспринимать сгенерированный код как готовый к применению результат, минуя обязательный этап критического ревью, который применялся бы к коду, написанному человеком.