A AWS lança emulador local escrito inteiramente por agentes autônomos de IA

A AWS lançou o AWS Emulator em 11 de novembro de 2026: um emulador local, disponível para todos, criado a partir de 438 modelos de API da AWS que abrangem mais de 200 serviços. Agentes autônomos de IA escreveram e testaram seu código, oferecendo a desenvolvedores e agentes de programação uma maneira de testar APIs da AWS em suas próprias máquinas, sem precisar de uma conta da AWS.

A AWS CLI, os AWS SDKs e os agentes de programação se conectam por meio de um endpoint HTTPS local, usando as mesmas APIs que usariam na nuvem. Variáveis de ambiente redirecionam essas ferramentas para a máquina do usuário, sem alterar o código da aplicação. Uma publicação de lançamento da AWS detalha pacotes RPM e Debian para Linux, Docker no macOS e no Windows e um modo incorporado para testes em Rust. Não há cobrança adicional pelo serviço, embora os clientes continuem pagando pelos recursos da AWS que implantarem na nuvem.

Para os agentes de programação, o emulador incorpora a infraestrutura da AWS a um ciclo de escrever, executar e ler: um agente pode criar um recurso, inspecionar o resultado e revisar o código sem esperar pela implantação em uma região da AWS. A documentação da AWS também cita servidores de desenvolvimento e integração contínua como ambientes para o emulador, nos quais as solicitações são direcionadas a recursos emulados, e não à AWS.

Três equipes de agentes criam e mantêm o código

Matthew Goldberg, engenheiro principal sênior da AWS, afirmou em um relato sobre engenharia que sua equipe não escreveu nem revisou o código do emulador. Em vez disso, as pessoas construíram a estrutura de suporte ao trabalho, incluindo as especificações, os mecanismos de teste, as barreiras para mesclagem e o pipeline de lançamento. O projeto começou quando o agente de programação Kiro produziu um emulador funcional do Amazon SQS em cerca de 15 minutos, a partir de uma instrução para escrever testes, validá-los com a AWS real e criar uma implementação em memória que fosse aprovada neles. Em seguida, Goldberg pediu ao Kiro que ampliasse o protótipo durante um fim de semana; para transformá-lo em um produto robusto, foram necessárias as salvaguardas ao redor do trabalho.

Três equipes de agentes, cada uma com escopo delimitado, agora dividem o trabalho. Os agentes responsáveis por escrever testes criam cenários a partir de modelos públicos de API e os verificam com a AWS real. Os agentes que identificam problemas executam os testes novamente e agrupam as falhas que podem ter uma causa raiz em comum, enquanto os agentes de correção assumem um problema cada. Goldberg relata dezenas de milhares de testes de fidelidade, com milhares de problemas corrigidos diariamente enquanto centenas de agentes trabalham em paralelo.

Toda correção proposta precisa ser compilada e aprovada em verificações automatizadas de padrões de programação, segurança e fidelidade antes de ser mesclada. Um agente de segurança independente analisa as alterações de forma adversarial durante o desenvolvimento e novamente no pipeline de lançamento. “Sem essa barreira para mesclagem, não confiaríamos no que nossos agentes estão construindo”, escreveu Goldberg.

As alterações passam então pelo AWS CodeCommit e pelo CodePipeline antes de serem publicadas no GitHub. O repositório público disponibiliza o histórico de commits e pastas separadas para problemas de fidelidade resolvidos e não resolvidos. A AWS publicou o código sob a licença CC0, uma dedicação ao domínio público, com exceção do código de fornecedores, disponibilizado sob a licença Apache 2.0; o repositório não aceita solicitações de pull, embora os usuários possam relatar erros e lacunas de fidelidade por meio do GitHub Issues.

As pontuações de fidelidade definem os limites

Um teste de fidelidade é um fluxo de trabalho curto verificado com a AWS real. Para ser aprovado, o emulador precisa reproduzir a resposta a cada chamada, incluindo o código de status, o corpo e o código e a mensagem de erro exatos, além dos recursos e dados criados pelo fluxo de trabalho. Operações não implementadas retornam HTTP 501 (Não implementado), de modo que as falhas aparecem imediatamente. Cada versão informa a quantidade de testes aprovados por serviço, e a AWS alerta que a inclusão de testes pode reduzir uma pontuação mesmo quando o emulador melhora.

Todos os testes da suíte pública de avaliação foram verificados em pelo menos duas contas da AWS isoladas em ambientes de teste, e o repositório deixa claro que comportamentos sem testes não foram verificados.

Essas pontuações não transformam o emulador em um ambiente de testes de segurança. Ele não avalia o AWS Identity and Access Management (IAM) nem as políticas baseadas em recursos da mesma forma que a AWS, portanto uma solicitação que a AWS recusaria pode ser aceita localmente. O uso previsto é para desenvolvimento e testes; cargas de trabalho de produção e testes de segurança de aplicações estão fora do escopo. Cada instância destina-se a uma única conta e região, mantém os recursos em memória e os exclui ao ser interrompida.

O trabalho de engenharia passa a se concentrar em especificações e testes

Na publicação de lançamento, Swaminathan Sivasubramanian descreveu o papel do engenheiro como decidir o que deve ser construído e criar as especificações, os testes e as barreiras para mesclagem que determinam o que é considerado correto, enquanto os agentes escrevem e verificam o código.

A comparação que ele fez com Alf, um dos primeiros serviços distribuídos de bloqueio da Amazon, oferece um exemplo concreto. O mecanismo de replicação original levou cerca de quatro meses para ser construído. Sivasubramanian disse que uma reconstrução com o Kiro consumiu primeiro quatro noites de trabalho supervisionado, pois o agente não tinha como verificar os resultados; depois que ele forneceu uma especificação e um ambiente de testes, a reconstrução levou cerca de duas horas.

O AWS Emulator transforma essa lição em um produto lançado: os agentes geram e corrigem a implementação, enquanto os engenheiros definem o comportamento aceitável e automatizam sua aplicação. Seu alcance prático agora depende da expansão da suíte pública de testes e das lacunas de fidelidade ainda existentes; a validação de segurança e de produção continua exigindo a AWS real.