IaC

Infrastructure-as-Code foi, por uma década, o exercício de escrever à mão a descrição declarativa da sua infraestrutura e deixar uma ferramenta (Terraform, OpenTofu, Pulumi, Ansible) reconciliar o mundo com aquela descrição. A entrada dos LLMs nessa rotina começou pelo lugar óbvio, gerar o trecho de HCL que você ia digitar de qualquer jeito, e é fácil descartar isso como autocompletar turbinado. Mas entre 2024 e 2026 o que era autocompletar virou outra coisa: plataformas agênticas que leem o estado vivo da nuvem, propõem refatorações, abrem pull requests e, sob supervisão configurável, conduzem o deploy.

Vale separar com cuidado o que dessa promessa já é produto que você pode usar hoje do que ainda é demonstração de laboratório, porque a distância entre os dois é justamente onde mora o risco. Em IaC essa distância tem um nome concreto: o apply. Gerar código que parece certo é barato e reversível; aplicar esse código contra infraestrutura viva, onde um terraform apply mal calculado destrói um banco de produção, não é. É essa assimetria que organiza todo o resto.

Da geração de trechos à plataforma agêntica

A camada mais madura, e a menos surpreendente, é a geração de IaC a partir de linguagem natural. Ela já aparece como recurso de produto em três frentes distintas, e a diferença entre elas diz algo sobre o estado do campo.

O Amazon Q Developer gera código e módulos Terraform para casos concretos de AWS, com a vantagem de operar dentro do provedor cuja infraestrutura ele descreve: a partir de um pedido em inglês, monta VPC e networking, pipelines de CI/CD, arquiteturas event-driven, serviços em ECS Fargate, workflows de SageMaker, e gera junto os artefatos de segurança que costumam ser esquecidos, como políticas IAM e security groups. O Pulumi Neo segue o mesmo princípio para o ecossistema Pulumi, criando programas em TypeScript, Python, Go e outras linguagens a partir de um prompt, dentro das best practices da ferramenta.

O caso mais instrutivo é o do Red Hat Ansible Lightspeed com IBM watsonx Code Assistant, que gera playbooks, tasks e roles a partir de prompts em inglês. O detalhe que importa é o motor: em vez de um modelo de código genérico, ele usa um LLM IBM Granite treinado especificamente em conteúdo Ansible (Ansible Galaxy, repositórios Git públicos, exemplos curados por especialistas da Red Hat). A aposta por trás disso é que IaC não é só código, é código com um vocabulário estreito e convenções fortes, e que um modelo especializado nesse vocabulário erra menos nos detalhes idiomáticos do que um generalista que viu de tudo um pouco. Se essa aposta se confirma de forma mensurável é outra conversa, e uma para a qual ainda faltam números independentes, mas a direção arquitetural é um sinal de para onde a geração de IaC tende: especialização, não um único modelo para tudo.

Descobrir, padronizar e remediar o que já existe

Gerar código novo é o problema fácil. O problema que dói nas operações reais é o inverso: você já tem nuvem rodando, boa parte dela provisionada na mão ou por times diferentes, e nada disso está no seu IaC. É aqui que os agentes começam a entregar algo que a geração de snippets não entregava.

O Codification Agent da Firefly descobre recursos não gerenciados e de terceiros across providers (AWS, Azure, GCP, OCI), mapeia as dependências entre eles, e gera IaC padronizado (Terraform, OpenTofu ou Pulumi) para o que encontrou. Como o grafo de dependências é explícito, a mesma capacidade habilita migração entre provedores com tradução contextual, transformar uma EC2 da AWS em uma VM equivalente no Azure ou no Compute Engine, em vez de só copiar atributos. O que antes era um trabalho arqueológico de importar recurso por recurso vira uma operação que o agente conduz.

O outro lado dessa moeda é o drift, a divergência que se acumula quando alguém muda um recurso direto no console e o código deixa de refletir a realidade. O Drift Remediation Agent da Firefly detecta essa divergência entre o IaC e o estado real e gera a correção, seja como ajuste no Terraform, seja como comando de CLI, podendo abrir um pull request com a mudança ou fornecer um comando de reversão. O fornecedor afirma que o agente evita falsos positivos e breaking changes, com mecanismos documentados como regras de exclusão de drift. Convém ler “evita” como objetivo declarado, não como garantia benchmarkada: a salvaguarda real continua sendo o review antes do apply, e é nele que você deveria confiar, não na promessa de que a ferramenta nunca erra.

Plano, política e os freios do human-in-the-loop

Entre gerar o código e aplicá-lo está o plan, e ele é um terreno natural para um agente, porque interpretar um diff de plano é exatamente o tipo de tarefa de linguagem em que LLMs são bons. O Plan Implications Engine da Firefly lê planos de Terraform e OpenTofu, explica em linguagem natural quais políticas seriam violadas, e prevê o impacto de uma mudança levando em conta dependências, drift e regras de governança. No mesmo eixo, a ferramenta gera policy-as-code: você descreve a regra em inglês e ela produz o Rego correspondente para o OPA, transformando uma intenção de compliance em código executável sem que você precise dominar a sintaxe da linguagem de política.

A governança é também onde o Pulumi Neo concentra suas garantias. Ele aplica automaticamente as políticas que a organização já configurou (RBAC, regras de compliance, padrões de segurança) e pode varrer a infraestrutura em busca de misconfigurations a partir de uma única pergunta. O ponto de desenho relevante é que o agente opera dentro dos limites de RBAC já existentes, em vez de transcendê-los, o que é a única postura defensável para um agente com acesso a infraestrutura de produção.

E é por isso que o controle de autonomia vira o recurso central, não um detalhe de configuração. No Pulumi Neo, cada ação é previewada, logada e reversível, e o nível de autonomia é configurável por ação, indo de totalmente guardrailed a totalmente autônomo, com approval gates que pausam o agente para autorização humana explícita e deixam um audit trail. A leitura honesta dessa lista de recursos é que ela descreve precisamente o que ainda não se confia a um agente: a existência de approval gates como recurso de destaque é a confissão de que o apply sem supervisão não é o modo padrão recomendado, e sim a ponta extrema de um dial que a maioria mantém girado para o lado conservador.

O agente dentro do IDE: MCP como vetor

Um vetor de integração que merece nota própria é o MCP, porque ele é o que conecta o estado vivo da infraestrutura aos agentes que já vivem no seu editor. Em setembro de 2025 o env0 lançou um MCP Server open-source que expõe o estado da infraestrutura a agentes locais em IDEs como VS Code e Cursor, e a clientes como o GitHub Copilot e o Claude. Com ele, dá para inspecionar ambientes (aprovações pendentes, runs que falharam, mudanças ativas), depurar erros com sugestões de correção sensíveis ao contexto, e disparar deployments (aprovar, cancelar, rerodar) sem trocar de ferramenta. O que o MCP acrescenta aqui não é uma capacidade nova de deploy, e sim levar o contexto da nuvem para dentro do lugar onde o desenvolvedor já está raciocinando, que é o tipo de portabilidade entre hosts para o qual o protocolo foi desenhado.

Na mesma safra, o env0 enviou um Code Optimizer (em beta, novembro de 2025) que escaneia os arquivos de IaC dentro do fluxo de Git e sugere melhorias que vão além do linting: transformar valores hardcoded em variáveis, endurecer configurações de recursos por segurança. É uma diferença de ambição em relação a um linter tradicional, que aponta o que está fora do padrão; o agente propõe a refatoração já escrita. Sendo um recurso beta, a eficácia ainda não foi testada de forma independente, e a ressalva geral sobre fontes (logo abaixo) se aplica com força redobrada aqui.

A fronteira: reconciliar no sentido do código

Tudo que as ferramentas comerciais fazem com drift segue, no fundo, a mesma direção: detectada a divergência, elas empurram a infraestrutura viva de volta para casar com o código, ou propõem que você ajuste o código para o que já existe, sempre com o humano no comando da decisão. A direção genuinamente difícil é a inversa e ainda não resolvida: propagar automaticamente uma mudança feita fora do IaC de volta para o programa, atualizando o código para capturar a mudança intencional em vez de sobrescrevê-la, e fazê-lo sem quebrar o resto.

Esse é o problema que o NSync ataca, um trabalho acadêmico-industrial de University of Michigan e AWS publicado no arXiv em outubro de 2025. O próprio paper é direto sobre o estado da arte: não existe solução totalmente automatizada para a reconciliação de IaC hoje. A relevância do trabalho, para um panorama, está menos nos números que ele reporta (que não sobreviveram a uma verificação independente e por isso ficam de fora aqui) e mais em demarcar com precisão onde acaba o que já é produto e começa o que ainda é pesquisa.

O que ainda trava o apply autônomo aparece, de forma reveladora, na boca do próprio fornecedor mais bem posicionado para vender o contrário. A AWS adverte explicitamente que o Terraform gerado pelo Q Developer deve ser validado e testado em um ambiente seguro antes de ir para produção, porque pode não cobrir todos os edge cases e exige revisão e modificação manual. Quando o fabricante da ferramenta de geração inclui esse disclaimer, ele está dizendo que correção de estado, blast radius e segurança continuam sendo gargalos para a autonomia plena, não promessas já cumpridas. Por baixo disso há um problema ainda mais básico e sem solução automatizada: distinguir o drift intencional do acidental. Sem resolver essa distinção, não há como reconciliar código com segurança nem confiar um apply a um agente, porque o agente não tem como saber se aquela mudança no console foi um conserto emergencial que deve ser preservado ou um engano que deve ser revertido.

Uma palavra sobre a qualidade das fontes

Convém ser explícito sobre uma fragilidade que atravessa todo este panorama. Quase toda a evidência sobre os produtos comerciais citados (env0, Firefly, Pulumi Neo, Amazon Q, Ansible Lightspeed) vem de fontes primárias dos próprios fornecedores: páginas de marketing, blogs de lançamento, documentação oficial. São descrições de capacidades anunciadas e de funcionalidades que existem, não de desempenho medido por terceiros em produção. Métricas promocionais do tipo “11x mais rápido” ou “de dias para horas” foram tratadas como não confiáveis e deliberadamente deixadas de fora. Onde um fornecedor diz “evita falsos positivos” ou “segue as best practices”, isso é asserção dele, não resultado comprovado.

A consequência prática para quem lê este texto como referência de decisão é simples: trate a lista de capacidades como o que o mercado afirma entregar, e reserve o ceticismo para os pontos em que a afirmação é mais conveniente ao vendedor, justamente segurança, ausência de falsos positivos e prontidão para autonomia. A evidência mais robusta deste panorama é a acadêmica, não por ser mais nova, mas por não ser material de venda: é ela que enquadra a reconciliação no sentido do código e o apply autônomo confiável como problemas ainda abertos, e essa moldura é a parte do mapa em que vale mais confiar.

Fontes

Palavras-chave

Conceitos: Infrastructure-as-Code, IaC, drift, reconciliação, apply, plan, policy-as-code, blast radius, human-in-the-loop, approval gates, RBAC, codificação de recursos órfãos Ferramentas: Terraform, OpenTofu, Pulumi, Ansible, HCL, Rego, OPA Produtos: Amazon Q Developer, Pulumi Neo, Ansible Lightspeed, watsonx Code Assistant, Firefly, env0 Pesquisa: NSync, University of Michigan, AWS Protocolos: MCP