Por que o agente de código precisa de um revisor com contexto zerado antes do deploy na AWS

O "done, verified" do agente não é uma revisão

Um desenvolvedor que publica na DEV Community sob o usuário bitpage está construindo um produto do zero com um agente de código fazendo a implementação de ponta a ponta. Em um post recente, ele conta três episódios do mesmo projeto, ainda em andamento (três de dezessete etapas concluídas). No estágio de importação de catálogo, o agente reportou o código pronto e verificado.

Um revisor com contexto zerado, isto é, sem histórico da conversa nem do raciocínio que gerou o código, encontrou 2 defeitos sérios, incluindo uma falha que unificava silenciosamente registros de livros diferentes. No estágio seguinte, o esqueleto da API, o mesmo tipo de revisor leu só o plano, antes de qualquer código existir, e devolveu 9 problemas bloqueantes.

O argumento central do post é mecânico, não moral: um agente que revisa o próprio trabalho está checando esse trabalho contra o mesmo modelo de falha que o produziu. A lista de riscos que ele verifica é exatamente a lista de riscos que ele já considerou, o que é o conjunto com menor chance de conter o erro real.

No contexto de raciocínio, nossa pesquisa indica que LLMs têm dificuldade para autocorrigir suas respostas sem feedback externo e, às vezes, o desempenho piora depois da autocorreção.

In the context of reasoning, our research indicates that LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction.Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet (ICLR 2024)

A fonte cita essa pesquisa para derrubar a suposição barata de que um segundo passo do mesmo agente já conta como revisão. O ponto mecânico que torna um revisor separado diferente está na documentação do Claude Code sobre subagentes:

Cada subagente começa com uma janela de contexto nova e isolada. Ele não vê o histórico da conversa, as skills já invocadas, nem os arquivos que o Claude já leu.

Each subagent starts with a fresh, isolated context window. It doesn't see your conversation history, the skills you've already invoked, or the files Claude has already read.Documentação do Claude Code, Anthropic

A ordem que virou regra no repositório

O autor transformou a lição em um registro de decisão que o agente lê antes de cada etapa:

• Plano em tópicos grossos, sem código
• Revisão independente do plano, por um agente de contexto zerado
• Desenvolvimento
• Exatamente uma revisão independente do código
• Correções, sem segunda revisão
• Verificação lendo código e rodando queries reais
• Atualização do mapa do projeto e dos documentos

Os 9 problemas achados no esqueleto da API, antes do código existir, incluíam três que valem citar pelo peso que carregam: nenhum modelo de acesso ao banco tinha sido escolhido (e essa escolha seria copiada em todo endpoint construído depois), uma conta deletada apareceria ao próprio dono como bloqueada, e uma falha de banco de dados poderia ser apresentada como sessão perdida, derrubando usuários durante uma instabilidade. Uma revisão de código acha um bug numa função. Uma revisão de plano acha um bug num padrão prestes a ser carimbado em todos os endpoints seguintes.

O que isso muda pra quem já conhece change set

A AWS já tem um artefato equivalente ao "plano" do post: o diff antes do apply. É esse diff, não o código final, que precisa passar pelo revisor de contexto zerado antes do passo irreversível.

Com CloudFormation, o passo é criar o change set e descrevê-lo antes de executar:

aws cloudformation create-change-set \
 --stack-name minha-app \
 --change-set-name revisao-pre-deploy \
 --template-body file://template.yaml

aws cloudformation describe-change-set \
 --stack-name minha-app \
 --change-set-name revisao-pre-deploy

Só depois de ler a saída do describe-change-set entra o execute-change-set. Com CDK, o equivalente é rodar cdk diff antes do cdk deploy; com SAM, é sam deploy --no-execute-changeset seguido de revisão manual do changeset gerado. Em qualquer um dos três, o erro comum é pular direto para o apply porque o agente já disse que o plano está correto.

O checklist que o revisor de contexto zerado precisa rodar

O revisor não precisa saber por que o agente escreveu aquele recurso daquele jeito. Ele precisa ler a saída do diff ou do change set procurando pelos erros que um agente comete com frequência ao gerar infraestrutura:

• Action: "*" ou Resource: "*" numa policy de IAM, em vez da ação e do ARN específicos
• PublicAccessBlockConfiguration desligado ou ausente num bucket S3 que deveria ser privado
• Chave de API, string de conexão ou segredo literal em Environment.Variables de uma função Lambda, em vez de uma referência ao AWS Secrets Manager ou ao SSM Parameter Store
• Regra de Security Group liberando 0.0.0.0/0 numa porta de banco de dados ou de administração
• iam:PassRole concedido sem condição, que deixa a função assumir qualquer role do ambiente

Um segundo chat do mesmo agente, só com o diff colado e a instrução de procurar exatamente esses cinco pontos, já reproduz boa parte do que o post descreve: um revisor que reconstrói a intenção a partir do artefato, sem herdar o ponto cego de quem escreveu o código.

O ALTER TABLE irreversível

O post resume o princípio que guiou o desenho do importador de catálogo numa única frase, comentário no próprio código: um merge perdido é barato, um merge errado não é. Dois registros que deveriam ter sido unificados custam um clique de um editor depois; dois livros diferentes fundidos num só registro têm que ser separados à mão, e cada reimportação subsequente desfaz o reparo manual.

Esse é exatamente o risco de uma migração gerada por agente contra um banco RDS ou uma tabela DynamoDB já em produção. No episódio da fonte, o rollback de uma migração que violou a própria regra do dono do produto saiu de graça porque o banco estava vazio. Em produção, não está. O equivalente prático é tirar o snapshot antes de aplicar qualquer migração que um agente escreveu:

aws rds create-db-snapshot \
 --db-instance-identifier prod \
 --db-snapshot-identifier pre-migration-2026-11-11

Para DynamoDB, o comando é aws dynamodb create-backup --table-name minha-tabela --backup-name pre-migration. O snapshot não substitui a revisão do plano da migração, mas transforma o passo irreversível em reversível, que é exatamente o que o post defende fazer antes de qualquer coisa que mexa em dado real.

Uma revisão só, não um loop

Um detalhe do processo que o autor deixa explícito: existe exatamente uma revisão por etapa, sem uma segunda rodada depois das correções. Um loop que roda até o relatório sair limpo converge para um relatório limpo, não para um código limpo, e cada volta custa dinheiro de verdade em chamadas de agente. Depois da única revisão, a responsabilidade volta para quem escreveu o código.

No contexto AWS isso também evita um vício comum: pedir pro agente reavaliar o próprio cdk diff até ele "aprovar", o que de novo é o mesmo modelo checando contra si mesmo.

O que fica de fora

O próprio autor é cauteloso: três de dezessete etapas concluídas é, nas palavras dele, uma hipótese com quase nenhum suporte ainda. Vale a mesma cautela aqui. Esse processo de revisão em contexto zerado não substitui as ferramentas automatizadas que já deveriam rodar em qualquer pipeline de infraestrutura como código, como cfn-lint, cdk-nag ou checkov, nem o IAM Access Analyzer para validar policies. Linters pegam sintaxe e padrões conhecidos de má prática; o revisor de contexto zerado pega o que depende de entender a intenção do plano, que é exatamente o tipo de erro que passa batido em ferramenta estática.

Passo a passo pra aplicar no seu repositório

1. Escreva a ordem de etapas num arquivo que o agente lê antes de cada deploy (CLAUDE.md, AGENTS.md ou equivalente), não numa instrução solta no chat.
2. Identifique explicitamente qual é o seu passo irreversível: cdk deploy em produção, uma migração destrutiva, um aws s3 sync sobrescrevendo um bucket, a virada de um registro em Route 53.
3. Antes desse passo, gere o diff (cdk diff, change set do CloudFormation ou plano do Terraform) e passe só esse artefato, sem o histórico da conversa, para uma sessão nova do agente.
4. Peça que essa sessão procure especificamente IAM com *, bucket público, segredo em variável de ambiente e security group aberto.
5. Tire o snapshot do banco antes de aplicar qualquer migração gerada por agente.
6. Permita uma revisão por etapa. Depois dela, a responsabilidade é de quem escreveu o código, não do loop.

Fonte: DEV Community — #claudecode