AWS rilascia un emulatore locale scritto interamente da agenti IA autonomi

L’11 novembre 2026, AWS ha rilasciato AWS Emulator, un emulatore locale disponibile a tutti, realizzato a partire da 438 modelli di API AWS che coprono più di 200 servizi. Agenti IA autonomi ne hanno scritto e testato il codice, offrendo a sviluppatori e agenti di programmazione un modo per provare le API AWS sui propri computer senza un account AWS.

AWS CLI, gli SDK AWS e gli agenti di programmazione si collegano tramite un endpoint HTTPS locale, usando le stesse API che userebbero nel cloud. Le variabili d’ambiente reindirizzano questi strumenti al computer dell’utente, senza modificare il codice dell’applicazione. Un post di lancio di AWS illustra i pacchetti RPM e Debian per Linux, Docker su macOS e Windows e una modalità integrata per i test in Rust. Non ci sono costi aggiuntivi per il servizio, anche se i clienti continuano a pagare le risorse AWS che distribuiscono nel cloud.

Per gli agenti di programmazione, l’emulatore integra l’infrastruttura AWS in un ciclo di scrittura, esecuzione e lettura: un agente può creare una risorsa, esaminare il risultato e modificare il codice senza attendere la distribuzione in una regione AWS. La documentazione AWS indica inoltre i server di sviluppo e l’integrazione continua tra gli ambienti in cui usare l’emulatore; le richieste vengono indirizzate alle risorse emulante, anziché ad AWS.

Tre team di agenti sviluppano e gestiscono il codice

Matthew Goldberg, ingegnere senior principale di AWS, ha dichiarato in un resoconto tecnico che il suo team non ha né scritto né revisionato il codice dell’emulatore. Gli esseri umani hanno invece predisposto le strutture di supporto a quel lavoro, comprese le specifiche, gli strumenti di test, i controlli per l’integrazione delle modifiche e la pipeline di rilascio. Il progetto è iniziato quando l’agente di programmazione Kiro ha prodotto un emulatore di Amazon SQS accettabile in circa 15 minuti, partendo da una richiesta di scrivere test, convalidarli con AWS reale e creare un’implementazione in memoria che li superasse. Goldberg ha poi chiesto a Kiro di ampliare il prototipo durante un fine settimana; per trasformarlo in un prodotto affidabile sono servite le misure di protezione circostanti.

Ora il lavoro è suddiviso tra tre team di agenti con compiti circoscritti. Chi scrive i test definisce scenari a partire dai modelli delle API pubbliche e li verifica con AWS reale. Gli agenti incaricati di individuare i problemi ripetono i test e raggruppano gli errori che potrebbero avere una causa comune, mentre gli agenti che li correggono si occupano ciascuno di un singolo problema. Goldberg riferisce che sono stati eseguiti decine di migliaia di test di fedeltà e che ogni giorno vengono risolti migliaia di problemi, mentre lavorano in parallelo centinaia di agenti.

Prima dell’integrazione, ogni correzione proposta deve essere compilata e superare controlli automatizzati sugli standard di programmazione, la sicurezza e la fedeltà. Durante lo sviluppo e di nuovo nella pipeline di rilascio, un agente di sicurezza indipendente esamina le modifiche adottando un approccio avversariale. «Senza questo controllo prima dell’integrazione, non ci fideremmo di ciò che stanno realizzando i nostri agenti», ha scritto Goldberg.

Le modifiche passano poi da AWS CodeCommit e CodePipeline prima di essere pubblicate su GitHub. Il repository pubblico rende accessibili la cronologia dei commit e cartelle separate per i problemi di fedeltà risolti e non risolti. AWS ha pubblicato il codice con CC0, una dedica al pubblico dominio, fatta eccezione per il codice dei fornitori, distribuito con licenza Apache 2.0; il repository non accetta richieste di pull, ma gli utenti possono segnalare bug e lacune di fedeltà tramite GitHub Issues.

I punteggi di fedeltà definiscono i limiti

Un test di fedeltà è un breve flusso di lavoro verificato con AWS reale. Per superarlo, l’emulatore deve restituire per ogni chiamata una risposta corrispondente, compresi il codice di stato, il corpo e il codice e il messaggio di errore esatti, oltre alle risorse e ai dati creati dal flusso di lavoro. Le operazioni non implementate restituiscono HTTP 501 (Not Implemented), perciò gli errori emergono subito. Ogni versione riporta il numero di test superati per ciascun servizio e AWS avverte che l’aggiunta di test può abbassare un punteggio anche quando l’emulatore migliora.

Ogni test della suite pubblica di valutazione è stato verificato con almeno due account AWS isolati in ambienti sandbox; il repository chiarisce inoltre che i comportamenti non coperti da un test non sono verificati.

Questi punteggi non fanno dell’emulatore un ambiente per i test di sicurezza. Non valuta AWS Identity and Access Management (IAM) né le policy basate sulle risorse come fa AWS, quindi una richiesta che AWS rifiuterebbe potrebbe riuscire in locale. L’emulatore è pensato per lo sviluppo e i test; i carichi di lavoro di produzione e i test di sicurezza delle applicazioni non rientrano nel suo ambito. Ogni istanza è destinata a un solo account e a una sola regione, conserva le risorse in memoria e le elimina quando viene arrestata.

Il lavoro di progettazione si sposta sulle specifiche e sui test

Nel post di lancio, Swaminathan Sivasubramanian ha descritto il ruolo dell’ingegnere come quello di decidere che cosa realizzare e creare le specifiche, i test e i controlli per l’integrazione che stabiliscono i criteri di correttezza, mentre gli agenti scrivono e verificano il codice.

Il paragone con Alf, uno dei primi servizi di lock distribuito di Amazon, offre un esempio concreto. Per realizzare il motore di replica originale sono serviti circa quattro mesi. Sivasubramanian ha raccontato che una ricostruzione con Kiro ha richiesto inizialmente quattro notti supervisionate, perché l’agente non aveva modo di verificare i risultati; dopo che gli ha fornito una specifica e un ambiente di test, la ricostruzione è durata circa due ore.

AWS Emulator trasforma questa lezione in un prodotto distribuito: gli agenti generano e correggono l’implementazione, mentre gli ingegneri definiscono i comportamenti accettabili e ne automatizzano l’applicazione. La sua utilità pratica dipende ora dalla crescita della suite pubblica di test e dalle lacune di fedeltà ancora presenti; per la sicurezza e la convalida in produzione è ancora necessario ricorrere ad AWS reale.