CloudArchitect Lite impede que LLM invente serviço AWS inexistente

Pedir uma arquitetura AWS para um LLM dá uma resposta confiante. O problema é que confiança não é precisão: o modelo pode citar um serviço que não existe, uma feature inventada, ou colocar um banco de dados flutuando fora de qualquer VPC. E quando isso vira diagrama, fica pior ainda, porque um desenho limpo parece mais confiável do que o texto furado que o gerou.

Foi esse problema que o engenheiro Aliaksandr Liapin atacou no post How I stop an LLM from inventing cloud services, publicado na DEV Community. Ele construiu o CloudArchitect Lite, uma ferramenta que transforma descrição em inglês simples em diagrama AWS, e documentou os três mecanismos que seguram o modelo na linha. A versão atual é a 0.2, marcada pelo próprio autor como pré-alfa: ele é direto sobre onde a evidência ainda é fraca.

Se você já usa agente de código para rascunhar infraestrutura (CloudFormation, CDK, Terraform ou só um diagrama de arquitetura), o padrão aqui vale o trajeto inteiro, não só para AWS.

O que você vai construir

Você vai subir o CloudArchitect Lite localmente via Docker, ligá-lo à sua própria chave da Anthropic e gerar uma arquitetura AWS a partir de uma descrição em linguagem natural. No fim, você vai ter visto na prática os três mecanismos que travam a alucinação: um catálogo fechado de 38 serviços AWS que restringe o que o modelo pode gerar, uma válvula de escape para quando o catálogo não cobre o pedido, e um conjunto de 25 regras determinísticas (VR-001 a VR-025) que validam o grafo depois da geração, sem depender da boa vontade do modelo.

Quem só quer ver o resultado sem instalar nada pode abrir o editor clicável no navegador. Mas o passo a passo abaixo roda a stack completa, com a geração via API de verdade.

Pré-requisitos

Para seguir este tutorial você precisa de:

• Docker e Docker Compose instalados (o autor testou macOS em Apple Silicon à mão; o CI testa Linux a cada release; Windows roda via Docker Desktop mas ainda não foi testado manualmente, então relatos são bem-vindos)
• Uma chave de API da Anthropic própria, com faturamento ativo na sua conta
• curl (no Windows, use PowerShell com curl.exe, como descrito no README do projeto)
• Nenhuma conta AWS é necessária: a ferramenta só gera o diagrama e valida a topologia, não cria recurso real na nuvem

Vale avisar de cara sobre custo: segundo o Gate A report do autor, cada geração com Claude Haiku 5.5 custa cerca de 0,007 dólar, e com Claude Sonnet 5.5 cerca de 0,045 dólar. O assistente de configuração define limites de gasto diário e mensal, então não há risco de fatura surpresa se você configurar esse teto.

Passo a passo

1. Suba a stack. O projeto distribui um compose.yaml pronto:

curl -fsSLO https://raw.githubusercontent.com/aliaksandr-liapin/cloudarchitect-lite/v0.2.1/compose.yaml && docker compose up

2. Passe pelo assistente de configuração. Ele valida a chave da Anthropic, deixa você escolher entre Haiku ou Sonnet, e pede os limites de gasto diário e mensal antes de liberar o uso.

3. Entenda o catálogo fechado. O app mantém um catálogo com 38 serviços AWS, cada um com id, mapeamento de ícone e as chaves de configuração que fazem sentido para aquele serviço. O modelo não escreve JSON livre: ele gera contra um schema de saída estruturada, e esse schema é montado a partir do catálogo. O campo serviceId é um enum com os ids do catálogo; as chaves de configuração também são um enum. Decodificação restrita (constrained decoding) significa que o modelo literalmente não consegue emitir um serviceId fora da lista.

Isso não saiu de graça. A primeira versão do autor usava o helper do SDK que converte um schema em formato de saída, e esse helper jogava cada enum para dentro da descrição do campo em vez de mantê-lo como enum real. Resultado: o decoder deixou de ser restrito, e o Haiku emitiu chaves de configuração fora do catálogo em 2 das execuções de teste. A correção foi construir o JSON schema manualmente, preservando os enums como enums de verdade, com um teste unitário checando que eles continuam lá.

4. Trate o que o catálogo não cobre. Um catálogo fechado tem custo: às vezes o usuário pede algo que não está na lista. O schema tem uma válvula de escape. Um nó tem ou um serviceId do catálogo, ou um objeto unresolved com nome e justificativa:

{
  "id": "ext-1",
  "provider": "aws",
  "unresolved": {
    "name": "Amazon Rekognition",
    "rationale": "Photo moderation requirement"
  }
}

Um nó unresolved é desenhado como um bloco visivelmente genérico e nunca aparece como serviço AWS verificado. A regra VR-015 reporta isso como um finding (achado). O ponto central: "eu não conheço esse aqui" vira um estado explícito e visível, em vez de um chute silencioso.

5. Deixe as 25 regras fazerem o trabalho sujo. Depois da geração, um conjunto determinístico de regras (VR-001 a VR-025) checa o design inteiro. São funções simples sobre o grafo, cada uma com fixtures de teste positivos e negativos. Alguns exemplos citados pelo autor:

• Um consumidor assíncrono, como SQS para Lambda, sem dead-letter queue ou failure destination
• Um Application Load Balancer numa única Availability Zone
• RDS, Aurora, ElastiCache, EC2 ou EFS fora de um container de VPC
• Um banco de dados numa subnet pública
• AWS WAF associado a uma API Gateway HTTP API (o WAF só suporta API REST)
• Um requisito que nenhum nó satisfaz, ou um nó que nenhum requisito pediu

Como as regras são código, o modelo não consegue negociar a saída delas. Os findings aparecem no canvas e, no caso do Haiku, também alimentam um turno de reparo: o gerador manda os findings de volta, nomeando o id do nó ou da aresta problemática, e pede um design corrigido.

Duas lições que o autor descreve do jeito difícil valem a pena guardar:

Uma mensagem de reparo que só nomeia a regra não funciona; nomear os IDs dos nós e a correção, sim.

A repair message that only names the rule does not work; naming the node ids and the remediation does.Aliaksandr Liapin, autor do CloudArchitect Lite

A segunda: o campo containerId era opcional no schema de saída, e o modelo simplesmente o pulava em 18 das 59 gerações testadas. Bancos de dados ficavam fora de qualquer VPC e a regra de VPC disparava sem parar. Tornar o campo obrigatório (nulo apenas para nós externos) resolveu.

Testando

Com a stack no ar, descreva uma arquitetura em inglês simples, por exemplo um backend de e-commerce com processamento de pedidos via SQS e Lambda, com banco Postgres. O gerador produz o grafo, roda as 25 regras e mostra o diagrama com qualquer finding destacado, incluindo blocos unresolved se você mencionar algo fora do catálogo.

Os números do Gate A report dão uma régua para avaliar o quão confiável isso é hoje:

"Checagens automáticas" significa que os serviços exigidos estão presentes e não há finding de nível erro. As três falhas do Haiku foram serviço faltando, não violação de regra.

Para qualidade, o autor usou revisão cega: quatro sessões isoladas de Claude revisor pontuaram designs anonimizados numa rubrica de 0 a 3. Nos mesmos nove cenários base, Haiku teve mediana 2,00 e Sonnet 2,57; Sonnet foi preferido em 7 de 9 comparações pareadas. Em 12 cenários, o Haiku não teve defeito crítico em 11 deles.

O próprio autor pede para ler esses números com cuidado: os revisores são modelos Claude avaliando saída de modelos Claude, o que pode compartilhar pontos cegos; os pacotes de revisão vêm de antes das correções de container e enum descritas acima, então os diagramas avaliados eram piores do que os que rodam hoje; e o número 11 de 12 é a margem de um único design por variante. Alguns números até pioraram em relação a um spike anterior, e isso foi registrado no relatório em vez de escondido.

Vale notar que, nos comentários do post, o leitor Gautam K perguntou se o projeto também checa combinações inválidas de serviços reais, como banco fora de VPC, além de bloquear serviços inventados. A resposta já está no próprio mecanismo das 25 regras: catálogo fechado impede serviço fantasma, as regras VR-001 a VR-025 cobrem exatamente a topologia inválida entre serviços que existem de verdade.

Limpando os recursos

Como o CloudArchitect Lite não cria nenhum recurso AWS real, não há fatura de nuvem para zerar. A limpeza aqui é só local e de API:

1. Pare os containers com docker compose down
2. Remova as imagens baixadas com docker compose down --rmi all, se não for usar a ferramenta de novo tão cedo
3. Revise os limites de gasto diário e mensal definidos no assistente de configuração; se parou de usar, zere-os ou revogue a chave da Anthropic associada ao projeto
4. Confirme no console da Anthropic que nenhum uso residual ficou agendado contra a chave usada no teste

Próximos passos

O autor já anunciou o próximo passo: um benchmark público comparando Claude, GPT e Gemini nos mesmos cenários, para tirar o viés de "Claude avaliando Claude" da etapa de revisão atual. Quem quiser acompanhar o progresso tem o repositório no GitHub e o Gate A report linkado no post original.

Se você testar e a arquitetura sair errada, o pedido do autor é direto: abra uma issue com o prompt usado. Segundo ele, esses casos de falha são a coisa mais útil que alguém pode mandar agora, porque é exatamente o material que falta para fechar os buracos do catálogo e das regras.

Para quem desenvolve e usa agente de código no dia a dia, o padrão generaliza bem além de diagrama AWS: qualquer pipeline que peça a um LLM para gerar CloudFormation, CDK ou Terraform ganha com a mesma receita. Restrinja a saída a enums reais em vez de texto livre, dê ao modelo um jeito explícito de dizer "não conheço isso", e valide a topologia com regras determinísticas que o modelo não controla. O modelo pode errar; o que não pode é errar em silêncio.

Fonte: DEV Community — #aws