AWS lancerer lokal emulator, der udelukkende er skrevet af autonome AI-agenter

AWS udgav AWS Emulator den 11. november 2026. Det er en lokalt kørende emulator, der er bredt tilgængelig, og som er bygget på 438 AWS API-modeller, der dækker mere end 200 tjenester. Autonome AI-agenter skrev og testede koden, så udviklere og kodeagenter kan afprøve AWS API’er på deres egne maskiner uden en AWS-konto.

AWS CLI, AWS SDK’er og kodeagenter opretter forbindelse via et lokalt HTTPS-slutpunkt og bruger de samme API’er, som de ville bruge i skyen. Miljøvariabler omdirigerer værktøjerne til brugerens maskine, så applikationskoden ikke behøver at blive ændret. Et lanceringsindlæg fra AWS beskriver RPM- og Debian-pakker til Linux, Docker på macOS og Windows samt en indlejret tilstand til Rust-tests. Der er ingen ekstra serviceafgift, men kunderne betaler stadig for de AWS-ressourcer, de bruger i skyen.

For kodeagenter placerer emulatoren AWS-infrastrukturen i en løkke, hvor agenten skriver, kører og læser: Agenten kan oprette en ressource, undersøge resultatet og tilpasse sin kode uden at vente på, at den bliver udrullet i en AWS-region. AWS-dokumentationen nævner også udviklingsservere og kontinuerlig integration som miljøer, hvor emulatoren kan bruges, idet anmodningerne går til emulerede ressourcer i stedet for AWS.

Tre agenthold bygger og vedligeholder koden

Matthew Goldberg, senior principalingeniør hos AWS, sagde i en teknisk redegørelse, at hans team hverken skrev eller gennemgik emulatorens kode. I stedet byggede mennesker rammerne omkring arbejdet, herunder specifikationerne, testinfrastrukturen, mergekontrollerne og udgivelsespipelinen. Projektet begyndte, da kodeagenten Kiro på cirka 15 minutter skabte en brugbar Amazon SQS-emulator ud fra en prompt om at skrive tests, validere dem mod det rigtige AWS og bygge en implementering i hukommelsen, der bestod testene. Goldberg bad derefter Kiro om at udvide prototypen i løbet af en weekend; det krævede de omkringliggende sikkerhedsforanstaltninger at gøre den til et robust produkt.

Arbejdet er nu fordelt mellem tre agenthold med afgrænsede opgaver. Testforfattere udarbejder scenarier ud fra offentlige API-modeller og kontrollerer dem mod det rigtige AWS. Fejlfinderagenter afspiller testene igen og grupperer fejl, der kan have samme grundårsag, mens fejlrettende agenter tager sig af én fejl hver. Goldberg fortæller, at der er titusindvis af fidelitetstests, og at tusindvis af fejl rettes hver dag, mens hundredvis af agenter arbejder sideløbende.

Alle foreslåede rettelser skal kunne kompileres og bestå automatiske kontroller af kodestandarder, sikkerhed og fidelitet, før de flettes ind. En uafhængig sikkerhedsagent gennemgår ændringerne kritisk under udviklingen og igen i udgivelsespipelinen. »Uden denne mergekontrol ville vi ikke have tillid til det, vores agenter bygger,« skrev Goldberg.

Ændringerne går derefter gennem AWS CodeCommit og CodePipeline, før de offentliggøres på GitHub. Det offentlige kodearkiv viser commit-historikken og separate mapper for løste og uløste fidelitetsproblemer. AWS offentliggjorde koden under CC0, en erklæring om overdragelse til public domain, med undtagelse af leverandørkode, der er underlagt Apache 2.0. Arkivet tager ikke imod pull requests, men brugere kan indberette fejl og mangler i fideliteten via GitHubs problemsporing.

Fidelitetsscorer viser grænserne

En fidelitetstest er et kort arbejdsforløb, der kontrolleres mod det rigtige AWS. For at bestå skal emulatoren matche svaret på hvert kald, herunder statuskoden, indholdet samt den nøjagtige fejlkode og fejlmeddelelse, og også de ressourcer og data, som arbejdsforløbet opretter. Handlinger, der ikke er implementeret, returnerer HTTP 501 (Not Implemented), så fejl viser sig med det samme. Hver udgivelse angiver antallet af beståede tests for hver tjeneste, og AWS gør opmærksom på, at scoren kan falde, når der tilføjes tests, selv om emulatoren bliver bedre.

Hver test i den offentlige evalueringssuite blev verificeret mod mindst to AWS-sandkassekonti, og kodearkivet gør det klart, at funktionalitet, der ikke er dækket af en test, ikke er verificeret.

Disse scorer gør ikke emulatoren til et miljø til sikkerhedstest. Den evaluerer ikke AWS Identity and Access Management (IAM) eller ressourcebaserede politikker på samme måde som AWS, så en anmodning, som AWS afviser, kan lykkes lokalt. Emulatoren er beregnet til udvikling og test; produktionsarbejdsbelastninger og sikkerhedstest af applikationer er uden for dens anvendelsesområde. Hver instans er beregnet til én konto og én region, gemmer ressourcer i hukommelsen og sletter dem, når den stoppes.

Ingeniørarbejdet flytter fokus til specifikationer og tests

I lanceringsindlægget beskrev Swaminathan Sivasubramanian ingeniørens rolle som at beslutte, hvad der skal bygges, og udarbejde specifikationer, tests og mergekontroller, der fastslår, hvad der er korrekt, mens agenterne skriver og kontrollerer koden.

Hans sammenligning med Alf, en af Amazons tidlige distribuerede låsetjenester, giver et konkret eksempel. Det oprindelige replikeringsmodul tog cirka fire måneder at bygge. Sivasubramanian sagde, at en genopbygning med Kiro først tog fire overvågede nætter, fordi agenten ikke havde nogen måde at kontrollere sine resultater på. Efter at han havde givet den en specifikation og et testmiljø, tog genopbygningen cirka to timer.

AWS Emulator omsætter den erfaring til et udgivet produkt: Agenter genererer og reparerer implementeringen, mens ingeniører definerer den adfærd, der kan accepteres, og automatiserer håndhævelsen af den. Hvor nyttig emulatoren er i praksis, afhænger nu af, hvor meget den offentlige testsuite udvides, og hvilke mangler i fideliteten der stadig er tilbage; sikkerhedsvalidering og validering til produktionsbrug kræver fortsat det rigtige AWS.