AWS har udgivet et værktøj, som ingen ansat har læst koden i
Matt Goldberg var aldrig god til at tegne. I børnehaveklassen kunne han ikke holde ordentligt på en farveblyant, og da klassen skulle male en fælles kæmpetegning af dinosaurer, endte kammeraterne med at råbe ad ham, fordi han havde ødelagt deres del. Den historie bruger den ledende AWS-ingeniør til at forklare, hvorfor AI-agenter laver rod, og hvorfor de har brug for det, han kalder en malebog: et tydeligt område, de skal holde sig inden for.
Onsdag 11. november udgav Amazon Web Services AWS Emulator, en lokal kopi af AWS’ cloud, som udviklere kan køre gratis på deres egen maskine og teste deres programmer mod. Det opsigtsvækkende er, hvem der har lavet den. ”The emulator was written entirely by autonomous agents. Our team hasn’t written or reviewed any of the code”, skriver Goldberg på Amazons nyhedsside. Det gentager AWS’ egen lanceringsblog og Swami Sivasubramanian, der står for agentisk AI hos AWS, i et gæsteindlæg på teknologidirektør Werner Vogels’ blog.
En weekend til første udkast, meget længere til et produkt
Projektet begyndte som et weekendforsøg. Goldberg gav kodeagenten Kiro en prompt i tre trin: skriv test ud fra AWS’ kommandolinjeværktøj, ret dem, indtil de består mod det rigtige AWS, og byg så en version i hukommelsen, der består de samme test. Efter et kvarter havde han en brugbar første udgave af køtjenesten Amazon SQS. Over weekenden byggede Kiro en grov version af resten, og om mandagen brugte hans team den til at teste deres eget software. Ideen fik han ifølge både Amazon og GeekWire fra Anthropic, hvis Claude-agenter tidligere i år byggede en C-compiler.
Her vil mange stoppe op og konkludere, at man nu kan prompte sig til hele AWS. Det gør Goldberg ikke selv. Han skriver, at der er en naturlig fristelse til at tro, at AI kan bygge alt, og at det stadig kræver seriøst ingeniørarbejde at lave noget, man tør give til kunderne. Den del tog meget længere end en weekend.
Tre hold agenter og en port, alt skal igennem
I dag bygges emulatoren af tre hold agenter. Det første skriver såkaldte fidelity-test, små scenarier som at oprette en kø, sende en besked, modtage den og slette køen igen, og kører hver test mod det rigtige AWS, før den bliver godkendt. Ifølge Goldberg er der titusindvis af dem. Det andet hold kører testene mod emulatoren og opretter en sag for hver fejl. Det tredje får én sag pr. agent, finder årsagen og retter koden.
Ingen rettelse kommer ind i koden uden at passere en automatisk port. Koden skal kunne kompilere, andre agenter tjekker kodestandard og sikkerhed, og ændringen må ikke gøre emulatoren dårligere til at efterligne AWS. En selvstændig sikkerhedsagent gennemgår ændringerne igen i udgivelsesprocessen. ”Without this merge gate, we wouldn’t trust what our agents are building”, skriver Goldberg. Ifølge ham retter hundredvis af agenter tusindvis af fejl om dagen.
Fire nætter uden test, to timer med
Den bedste anekdote står i Swami Sivasubramanians indlæg. For omkring 20 år siden byggede han sammen med en af Amazons tidlige ingeniører replikeringsmotoren i Alf, en intern låsetjeneste, som AWS stadig bygger S3 og DynamoDB oven på. Første gang tog arbejdet omkring fire måneder. Da han i år bad Kiro bygge den igen, sad han fire nætter og holdt øje med agenten, før det gik op for ham, at den slet ikke havde nogen måde at kontrollere sine resultater på. Med en specifikation og et testmiljø tog opgaven cirka to timer.
Hans konklusion er værd at læse i originalen, fordi den er så nøgtern: ingeniørens opgave er at give agenterne plads og at bygge ”the specs, tests, and merge gates that decide when that work is correct”. Modellen var den samme de fire nætter og de to timer. Forskellen lå i rammerne.
Når agenterne bygger deres egen Python
Agenterne har heller ikke altid valgt den korteste vej. Goldberg fortæller, at en tidligere version af emulatoren fik sin egen hjemmebyggede Python-fortolker, fordi agenterne skulle understøtte AWS Lambda. Siden har de fået besked på at genbruge eksisterende biblioteker. Det siger noget om, hvordan agenter arbejder: de løser den opgave, de har fået, ret bogstaveligt, og hvis ingen har tegnet stregerne, tegner de selv nogle nye.
Hele forløbet ligger åbent. Koden er udgivet under CC0, en dedikation til det offentlige domæne, på GitHub med den fulde commit-historik, og agenternes sager ligger i to mapper, en for det, der virker, og en kaldet ”things-that-do-not-work”. Man kan selv gå på opdagelse i, hvad maskinerne har fundet og endnu ikke har løst.
Den efterligner AWS, men den efterligner ikke sikkerheden
Emulatoren er bygget ud fra mere end 400 af AWS’ API-modeller, der dækker over 200 tjenester. Den er skrevet i Rust, kører på Linux eller i Docker på Mac og Windows, svarer som udgangspunkt kun på din egen maskine og laver sine egne nøgler, der alle begynder med EMULATOR, så de ikke kan forveksles med rigtige. Det store salgsargument er, at en kodeagent kan oprette ressourcer, tjekke resultatet og prøve igen uden at vente på en udrulning i skyen og uden at betale for den.
AWS skriver selv tydeligt, hvad den ikke kan. Den vurderer ikke IAM-politikker og ressourcepolitikker, som AWS gør, så en forespørgsel, der ville blive afvist i skyen, kan godt gå igennem lokalt. Derfor må den ikke bruges til at teste, om en applikation er sikker. Hver emulator opfører sig som én konto og én region. Ifølge GeekWire har IDC-analytikeren Devin Pratt desuden over for InfoWorld peget på, at den ikke simulerer nedbrud, begrænsning af trafik eller forskelle mellem regioner. Vil man vide, om ens system holder, skal det stadig testes på det rigtige AWS.
Det er rammerne, der er produktet
For danske udviklingsteams, der bygger på AWS, er emulatoren først og fremmest et praktisk og gratis værktøj, og GeekWire noterer, at det mest kendte alternativ, LocalStack, i år har lagt sin gratis udgave bag et kontokrav og begrænset den til ikke-kommerciel brug. Men den vigtigste læring ligger i måden, den er lavet på. Overskriften er let at læse som et bevis på, at en prompt kan erstatte et udviklingsteam, og historien viser faktisk det modsatte. Agenterne kunne kun skrive koden alene, fordi mennesker havde bygget specifikationer, titusindvis af test kontrolleret mod virkeligheden og en port, som ingen ændring slipper udenom.
Den erfaring kender vi hos Snilld, hvor vi udvikler software med kodeagenter. Kvaliteten afgøres af den opsætning, der omgiver modellen: hvad agenten får at vide, hvordan den kan kontrollere sit eget arbejde, og hvem eller hvad der siger stop, før noget går videre. Det kaldes ofte harness engineering, og det er et håndværk, man lærer ved at gøre det mange gange.
Bundlinjen
AWS Emulator er et godt eksempel på, at kodeagenter kan bygge store systemer, og et endnu bedre eksempel på, hvad det kræver. Fire nætter med en agent uden test blev til to timer med test. Den slags tal bør stå på væggen i enhver virksomhed, der overvejer at lade AI skrive koden, for det viser, at investeringen ligger i alt det, der kontrollerer koden, og at selve koden er ved at blive den billige del.
Kilder
- Amazon (Matt Goldberg): AWS Emulator: a local emulator built 100% by autonomous AI agents (11. november 2026)
- All Things Distributed (Werner Vogels og Swami Sivasubramanian): AWS Emulator and the engineer’s job when agents write the code (11. november 2026)
- AWS News Blog: Test your applications against AWS locally with AWS Emulator (11. november 2026)
- GeekWire: AWS gives developers a free local stand-in for its cloud, built from scratch by AI agents (11. november 2026)
- Unite.AI: AWS Releases Local Emulator Written Entirely by Autonomous AI Agents (11. november 2026)
- Werner Vogels på X: Opslag om AWS Emulator (11. november 2026)
