Aprofundamento nº 09 4 min de leitura

E agora, o que muda no DevOps?

Quando o tempo de escrever código tende a zero com agentes como Claude Code e Codex, o gargalo não desaparece — ele se desloca. Migra para o provisionamento da infraestrutura. E a pergunta deixa de ser "como escrevo o Terraform?" para "onde mora a verdade do meu sistema?".

Acelerar a digitação do código sem repensar o provisionamento é trocar uma fila por outra. O gargalo não some — muda de endereço.

01 — Por que "infra no final" é a pergunta errada

Durante a década do DevOps, o fluxo era essencialmente sequencial: o desenvolvedor escrevia a aplicação, alguém (às vezes o próprio dev, às vezes uma equipe de plataforma) escrevia o Terraform correspondente, o pipeline rodava, e a infra era provisionada antes do deploy. A infraestrutura como código (IaC) foi a grande conquista desse período — transformou cliques manuais em arquivos versionados, repetíveis e auditáveis.

O problema é que esse modelo assume que escrever o código da aplicação e escrever o código da infra são tarefas de custo comparável. Os agentes quebram essa simetria. Quando o

02 — De camadas de tradução a uma camada de intenção

A articulação mais clara do novo modelo veio da engenharia da Microsoft, e vale entender porque ela mapeia bem o que os principais fornecedores estão construindo. No modelo tradicional, a IaC vive em uma pilha de tradução de várias camadas: a intenção humana (metas de arquitetura) é traduzida por uma camada de interação (CLIs, fluxos GitOps, pull requests, processos de UI) para uma abstração de IaC (Terraform HCL, Bicep/ARM, CloudFormation, módulos), que por fim aciona as APIs do provedor (AWS, Azure, GCP).

Essas camadas existem por uma razão: humanos não falam naturalmente o idioma dos schem

03 — O sistema de registro migra para cima

Aqui está a mudança conceitual mais profunda, e a que mais importa para um líder de tecnologia em ambiente regulado. Hoje, a IaC é o sistema de registro: o arquivo Terraform é a fonte canônica contra a qual o estado da plataforma é validado. Os agentes, por enquanto, operam através da IaC — geram, validam, reconciliam — mas não a substituem. Essa permanência não é acidental: a IaC entrega um modelo de estado desejado determinístico, histórico de mudanças versionado, planos revisáveis ("what-if", "plan") e um mecanismo de reconciliação de deriva. Para auditoria, rollback e gestão de mudança reg

04 — Aplicar nesta semana

Se a geração fosse o único desafio, o problema estaria resolvido. Não está. A experiência de campo de 2026 expôs três fragilidades concretas da IaC gerada por IA, e a visão de referência se organiza justamente em torno de mitigá-las.

Quando um agente chama a API da AWS diretamente, sem passar pela IaC, onde fica o estado? O Terraform rastreia cada recurso que criou — sabe o que existe, o que mudou e o que precisa ser destruído. Chamadas de API cruas não têm memória. Esse é o motivo central pelo qual a IaC não morre: ela é o mapa do que existe. O projeto Intent da Spacelift, lançado em outubro

Três camadas de enforcement

A resposta consolidada do mercado para esses três problemas não é confiar no agente — é cercá-lo de validação em camadas, de modo que a segurança seja inerente ao processo, não um portão que se atravessa. O padrão que emerge tem três momentos de enforcement, e é desenhado para que erros sejam barrados o mais cedo possível.

Em tempo de geração: o agente aplica os padrões da organização no momento em que escreve a IaC — instruções, contexto curado (arquiteturas de referência, políticas), e padrões aprovados que ele consome como conhecimento.
Em tempo de plano (plan-time): análise estática c

O time de plataforma deixa de entregar módulos

A consequência organizacional é direta. Por anos, a entrega de um time de plataforma foi o módulo: "aqui está o módulo, boa sorte com as 47 variáveis". O registro de módulos não morre, mas perde a centralidade. O novo artefato é o agente — e, por trás dele, o contexto que o governa.

O trabalho do time de plataforma migra de escrever IaC para shippar guardrails, padrões e agentes. Em termos concretos, isso significa produzir agentes de nível de repositório (que entendem um codebase específico) e de nível de organização (que codificam padrões corporativos — baselines de segurança, convenções de

O que muda para quem dirige tecnologia

Para um ambiente de adquirência ou serviços financeiros, três implicações são imediatas e merecem decisão de arquitetura, não apenas de ferramenta.

A primeira: a interação migra de sintaxe para intenção. As conversas de design sobem na pilha — passam a ser sobre o que queremos, não como expressá-lo em HCL. Isso valoriza o ativo que é mais escasso e mais difícil de terceirizar: a clareza arquitetural e a política bem escrita. Quem tem ADRs e arquiteturas de referência maduras larga na frente; quem tem só Terraform legado herda dívida.

A segunda: os guardrails entram no agente. Em um setor reg

Um stack inicial pragmático

A transição não exige um salto. Exige uma sequência. O caminho de menor risco começa pela camada de contexto e governança — não pela automação total — e só depois solta o agente para executar.

Escreva instruções e contexto antes de qualquer agente. Crie um arquivo de instruções base (regras de nomenclatura, tagging de centro de custo, provider preferido) e reúna ADRs, implementações de referência e padrões aprovados em um espaço de contexto. Isso é a fundação: o agente lê antes de gerar.
Codifique a política como código. OPA, Sentinel ou Azure Policy/SCPs — comece pelos controles inegociá

Perguntas frequentes

A Infraestrutura como Código (IaC) vai morrer?

Não no horizonte visível. A IaC perde o posto de "expressão primária da intenção", mas continua sendo o livro-razão determinístico do que existe — essencial para estado, rollback, auditoria e mudança regulada. A hipótese de futuro é que ela vire um formato de execução compilado, gerado a partir de política e arquitetura. Morre o HCL escrito à mão para a maioria dos casos; não morre a IaC como mecanismo de estado e reconciliação.

Posso deixar o agente provisionar direto na API e dispensar o Terraform?

Tecnicamente sim, na prática ainda não para a maioria dos casos. O problema é o estado: chamadas de API cruas não têm memória do que foi criado. Sem um mecanismo de estado, você perde rastreabilidade, detecção de deriva e capacidade de rollback. Projetos como o Spacelift Intent exploram esse caminho, mas é exatamente no gerenciamento de estado que a abordagem encontra seu limite hoje.

A infraestrutura entra depois do código e dos testes?

Não no modelo emergente. Ela é gerada em paralelo, pelo mesmo agente que produz a aplicação, e validada em três camadas (geração, plano, runtime) antes de existir. O modelo sequencial "código → teste → infra" dá lugar a um fluxo onde infra é propriedade contínua e governada, não etapa final. O "fim" linear desaparece.

Qual o maior risco da IaC gerada por IA em ambiente regulado?

Segurança por padrão. A IA otimiza para "funciona", não para "seguro por padrão" — gerando com frequência IAM permissivo demais, portas abertas e buckets sem bloqueio público. Em setor regulado, a mitigação é tornar a postura de segurança um critério de revisão de primeira classe e codificar os controles inegociáveis como política aplicada em tempo de plano e de runtime. A velocidade sem essa rede de política amplifica erros em escala.

O que o time de plataforma faz agora, se não escreve mais módulos?

Passa a shippar guardrails, padrões e agentes. Em vez de manter 50 módulos com dezenas de variáveis, o time produz agentes de repositório e de organização que carregam o contexto e os padrões da empresa, e mantém o corpus de política e arquitetura que esses agentes consomem. A manutenção migra de "atualizar módulos" para "atualizar o contexto do agente". O agente passa a ser um software versionado, testado e implantado como qualquer outro.

Receber os próximos aprofundamentos Abrir versão interativa

← Claude Security: O defensor em escala de máquina