AWS udgav onsdag den 11. november et værktøj kaldet AWS Emulator: en gratis, lokal kopi af AWS, som I kan køre på jeres egen maskine og teste kode imod uden en AWS-konto. Værktøjet er nyttigt i sig selv. Men den egentlige historie er, hvordan det er bygget. Hver eneste kodelinje er skrevet af autonome AI-agenter, og ifølge AWS har teamet bag hverken skrevet eller læst koden.
Vi har læst Matt Goldbergs lanceringsindlæg, Swami Sivasubramanians opfølgning, AWS-dokumentationen og selve GitHub-repoet, plus uafhængig dækning fra InfoWorld og SiliconANGLE. Herunder gennemgår vi, hvad emulatoren kan, hvad den udtrykkeligt ikke kan, og hvorfor metoden er mere interessant end produktet for jer, der overvejer at give AI-agenter mere at lave på egen hånd.
Emulatoren efterligner AWS' API'er lokalt. I starter den, peger jeres AWS CLI eller SDK mod dens endpoint med en miljøvariabel, og så kører jeres eksisterende kode uændret mod efterlignede ressourcer i stedet for den rigtige sky. Ifølge AWS-dokumentationen kræver den ingen AWS-konto, koster ingen servicegebyr, og I betaler først, når I deployer på den rigtige AWS. Requests, svar og ressourcedata forlader ikke maskinen.
Den er skrevet i Rust og kører som et lokalt HTTPS-endpoint på 127.0.0.1:9297. På Linux installeres den som en RPM- eller Debian-pakke, på macOS og Windows kører den i Docker, og til Rust-tests findes en indlejret tilstand, hvor emulatoren kører inde i selve testprocessen. Kildekoden ligger på GitHub under en CC0-licens, altså reelt frigivet til det offentlige domæne, bortset fra et vendor-bibliotek under Apache 2.0.
Dækningen er bred. Ifølge Swami Sivasubramanian er emulatoren bygget ud fra mere end 400 offentlige API-modeller, der dækker mere end 200 AWS-tjenester. Goldbergs eget indlæg nævner 438 API-modeller. En enkelt udlægning i pressen taler om 426 tjenester, men det stemmer ikke med AWS' egne tal, så hold jer til 200-plus tjenester og 438 modeller. Fidelitet, altså hvor tæt emulatoren rammer den rigtige AWS, varierer fra tjeneste til tjeneste, og AWS udgiver en fidelitets-score pr. tjeneste med hver udgivelse.
Idéen hviler på, at AWS har to ting, agenter kan arbejde ud fra: en specifikation i form af de offentlige Smithy-API-modeller, og en facitliste i form af den rigtige AWS-sky. Matt Goldberg, Senior Principal Engineer hos AWS, fik idéen efter at have set Anthropics forsøg, hvor parallelle agenter byggede en C-compiler fra bunden. Han gav kodeagenten Kiro én prompt: skriv tests ud fra AWS' CLI, ret dem til de består mod rigtig AWS, og byg så en implementering, de samme tests består imod. Kiro kom tilbage med en brugbar første version af Amazon SQS efter et kvarter.
Det voksede til tre hold af agenter, der kører på Amazon Bedrock AgentCore. Det første hold skriver fidelitets-tests ud fra API-modellerne og verificerer hver test mod den rigtige AWS, så testen registrerer, hvordan AWS faktisk opfører sig. Det andet hold afspiller testene mod emulatoren, finder de steder, hvor den afviger, og opretter en sag for hver fejlende test. Det tredje hold får én sag pr. agent, finder årsagen og retter koden.
Nøglen er en merge gate, som hver ændring skal igennem, før den kommer ind i kodebasen. Den afviser kode, der ikke kompilerer, og den kører agenter, der tjekker ændringen mod kodestandarder, verificerer at den er sikker, og sikrer, at fideliteten ikke falder. Goldberg skriver, at teamet ville ikke stole på det, agenterne bygger, uden den port. AWS oplyser, at hundredvis af agenter arbejder samtidig, og at der rettes tusindvis af sager om dagen. Repoet havde ved vores gennemgang knap 29.700 commits, alle agenternes, og hele historikken er offentlig.
Resultatet er et stort multi-agent-system, hvor hvert hold har en afgrænset opgave. Det er den samme opdeling, vi har set hos andre: 93 agenter, der byggede et operativsystem på tolv timer, og OpenAI Symphony, der lod agenter lande mange flere pull requests. Hvis I vil forstå designprincippet bag, har vi også skrevet en gennemgang af subagenter og afgrænsede opgaver.
Goldberg er direkte: emulatoren er skrevet udelukkende af autonome agenter, og teamet har hverken skrevet eller gennemlæst koden. De kunne gøre det, fordi de rammer, de har bygget rundt om agenterne, giver tilliden. Det er en stærk påstand, og den er værd at tage alvorligt på begge måder.
På den ene side viser det, at agentbaseret kodning kan skaleres, når der er en entydig facitliste og en kvalitetsport. Agenterne måles ikke på, om koden ser pæn ud, men på om tusindvis af tests opfører sig som den rigtige AWS. Det er en mere objektiv målestok end den, de fleste softwareteams har til rådighed. Goldberg fortæller også om en tidligere version, hvor agenterne på egen hånd byggede deres egen Python-fortolker til at håndtere Lambda-funktioner, før teamet gav dem besked på at genbruge eksisterende biblioteker. Det er både imponerende og en påmindelse om, hvor meget styring de kræver.
På den anden side er påstanden om nul menneskelig gennemlæsning et governance-spørgsmål. Ingen uafhængig part har revideret kvaliteten af de knap 30.000 commits, og tilliden hviler på AWS' egne kvalitetsporte. For virksomheder under NIS2 eller med krav om sikker softwareudvikling flytter det spørgsmålet: hvem kan dokumentere og stå inde for kode, som intet menneske har læst? Det gør ikke agentskrevet kode uansvarlig, men det hæver kravet til dokumenterede kontroller. Vores guide til EU AI Act gennemgår, hvor de krav lander.
Emulatoren er bygget til at bygge og teste, ikke til produktion, og AWS lister selv begrænsningerne. Den evaluerer ikke IAM- og ressourcepolitikker, som den rigtige AWS gør, så I kan ikke bruge den til at teste sikkerhed. Den efterligner ikke throttling, nedbrud eller snapshot og restore. Den holder ikke ressourcer adskilt pr. region eller konto, så I skal køre én region og én konto pr. instans, og alt ligger i hukommelsen og forsvinder, når I lukker den.
Adfærden er desuden kun verificeret mod amerikanske regioner: US West (Oregon) for de fleste tjenester og US East (N. Virginia) for globale tjenester. Forskelle i, hvilke tjenester og funktioner der findes i EU-regioner som Frankfurt, Irland og Stockholm, afspejles ikke. Det er en vigtig detalje, hvis jeres databehandling skal blive i EU.
De uafhængige stemmer peger på det samme. Devin Pratt, research director hos IDC, fremhæver over for InfoWorld, at netop throttling, nedbrud og regionsforskelle er det, der betyder mest for robusthed, og at emulatoren ikke simulerer dem. Broadcom-ingeniøren Advait Patel advarer samme sted om falsk tryghed: hvis jeres tests aldrig ser en 429 eller et timeout, bliver jeres retry- og backoff-logik aldrig afprøvet. Pratt påpeger desuden, at emulatoren ikke sandboxer den kode, den kører, så indeholder en testet funktion rigtige produktionsnøgler, kan koden stadig ramme rigtige AWS-ressourcer. Det er værd at lægge mærke til, netop fordi emulatoren ellers markedsføres som en sikker sandkasse til agenter.
Endelig sender emulatoren som standard anonyme brugs- og fejldata til AWS. Ikke jeres requests, svar, kode eller credentials, men telemetri. Den kan slås fra med flaget --telemetry off, miljøvariablen EMULATOR_TELEMETRY=off eller en linje i en konfigurationsfil. Bygger I emulatoren fra kilde, skal I regne med mindst 100 GB fri disk.
Den mest kendte lokale AWS-emulator er LocalStack, og timingen er næppe tilfældig. Fra den 23. marts 2026 kræver LocalStacks samlede image en brugerkonto og et auth-token, og det permanente gratisniveau er kun til ikke-kommerciel brug. AWS Emulator kommer gratis, uden konto og uden kommerciel begrænsning, med kildekoden frigivet til det offentlige domæne.
Holger Mueller fra Constellation Research kalder over for SiliconANGLE emulatoren en digital tvilling af AWS' offentlige sky, bygget udelukkende af agenter, og peger på, at det smarte er at flytte testarbejdet hen, hvor udviklerne sidder, nemlig på deres egne maskiner. Det hidtidige problem med tredjeparts-emulatorer har været, at de kun dækker en lille del af AWS' katalog og hurtigt kommer ud af sync, efterhånden som tjenesterne ændrer sig. Netop dér er agentmetodens pointe: AWS skriver, at emulatoren opdateres mange gange om dagen, så den følger med, når AWS-tjenester ændrer sig.
Swami Sivasubramanian, VP for agentic AI hos AWS, bruger lanceringen til at beskrive, hvordan ingeniørens arbejde ændrer sig. Hans pointe er, at når agenter skriver koden og tjekker deres eget arbejde, er ingeniørens opgave at give dem plads og at bygge de specifikationer, tests og kvalitetsporte, der afgør, hvornår arbejdet er korrekt.
Han illustrerer det med en personlig historie. For over tyve år siden var han med til at bygge en replikeringsmotor til et distribueret låseservice, der stadig ligger under tjenester som S3 og DynamoDB. Det tog omkring fire måneder dengang. I år prøvede han at genopbygge den med Kiro. Han overvågede agenten i fire nætter, før han indså, at den ikke havde nogen måde at kontrollere sine egne resultater på. Da den først havde en specifikation og et testmiljø, tog genopbygningen cirka to timer. Det, der gjorde forskellen, skriver han, var rammerne omkring agenten, altså specifikationen og testmiljøet.
Det er den samme lærdom, uanset om I bygger på AWS eller ej. En AI-agent leverer bedre, når den kan kontrollere sit eget arbejde undervejs. Uden en facitliste at måle imod bygger den noget, der ser rigtigt ud, men som ingen kan stå inde for. Kvaliteten afgøres af rammerne omkring agenten, mere end af selve modellen.
For jer, der bygger på AWS, er værktøjet værd at prøve med det samme. Men den vigtigste lærdom ligger i metoden mere end i selve produktet. AWS har vist en konkret skabelon for, hvordan man lader agenter arbejde selvstændigt uden at slippe kontrollen. Spørgsmålet for jer er ikke, om agenter skal skrive kode, men hvilke kontroller der skal være på plads, før I stoler på det, de laver.
Det kan I gøre nu:
På GDPR-siden er lokal test en fordel: testdata forlader ikke maskinen, og emulatoren sender ifølge AWS ikke requests eller ressourcedata videre, kun telemetri, der kan slås fra. Men påstanden om ingen menneskelig gennemlæsning trækker den anden vej for regulerede brancher. Agentskrevet kode kræver dokumenterede kontroller: tests, sikkerhedsscanninger og en merge gate. Leverandørens egne tal er ikke nok i sig selv.
AWS Emulator er på overfladen et testværktøj. Men AWS har pakket et argument ind i lanceringen: at verdens største cloududbyder kan sende et produkt ud, som ingen ingeniør har skrevet eller læst, og begrunde tilliden med specifikationer, tests og automatiske kvalitetsporte. At agenter kan skrive software, har AWS hermed vist. Det interessante er, hvor meget arbejde der ligger i de rammer, der afgør, hvornår arbejdet er korrekt. Den del kan intet menneske uddelegere endnu.