One Prompt, Fifteen Minutes, a Working Piece of the Cloud
Matt Goldberg typed a single prompt into Kiro and waited. He was not asking for a snippet of code. He was asking an AI coding agent to rebuild Amazon’s Simple Queue Service as a program that could run on an ordinary laptop — the first step toward what is now AWS Emulator.
Fifteen minutes later, he had a passable version of it. That small experiment has now become something much bigger. On November 11, 2026, Amazon released AWS Emulator, a free local copy of more than 200 AWS services. And according to Amazon, not a single line of its code was written by a human.
What AWS Emulator Actually Is
AWS Emulator is a program that serves AWS APIs from your own machine. Point the AWS command line, an SDK or a coding agent at it, and it answers the way the real cloud would — without ever touching the internet or charging a cent.
It runs as a local server on Linux, macOS and Windows, and it needs no AWS account at all. Everything happens through the same APIs developers already use, which is exactly the point: code written against the emulator should behave the same when it later runs against real AWS.
The breadth is what sets it apart. Amazon built the emulator from 438 public API models, covering more than 200 services. Earlier official tools covered one service at a time — DynamoDB Local, SAM Local, Step Functions Local — while LocalStack, the best-known independent option, now requires an account.
Amazon released the emulator’s source under CC0, a Creative Commons dedication to the public domain, and published the full commit history on GitHub. Anyone can download it, run it and read every line the agents wrote.
How AI Agents Built AWS Emulator
Goldberg’s idea was simple enough to state in one sentence: give an agent a written description of how a service should behave, plus the real service to check against, and see whether it can build a working copy on its own.
For AWS, the written description already existed — the public API models, written in Smithy, Amazon’s format for describing a service’s operations, inputs, outputs and errors.
The agents work from what Amazon calls fidelity tests. These are end-to-end customer scenarios drawn from the API models. A test might check, for example, that a message received from a queue stays hidden from other readers until its visibility timeout runs out.
The agents correct each test until it passes against real AWS, so the test becomes a faithful record of how the cloud actually behaves.
Only then do the agents build the emulator until it passes the same test. A test that still fails points at a gap in the emulator, and the agents go back to work on it. Hundreds of agents work on the project at once, in teams, each fixing the gaps they find.
Nothing enters the codebase unchecked. Every change passes through a merge gate, a deep bench of automated checks that includes several security agents doing adversarial reviews of each change, alongside a general code reviewer. Deterministic checks stop the agents from touching code they are not supposed to touch.
As Goldberg put it in his launch post, his team has not written or reviewed any of the code.
What It Can and Cannot Do
For developers, the emulator’s main job is speed. A coding agent works in a loop: it writes code, runs it and reads the result before deciding what to change next.
When the services it calls behave like the real ones, the agent can check its own work as it writes and produce correct code on its first attempt far more often.
That loop is why the emulator matters most for the new wave of agentic coding tools. Testing a pipeline built around S3, SQS, Lambda and DynamoDB can now take seconds on a laptop instead of minutes against the cloud, and run in CI without an AWS account.
But Amazon is blunt about the limits. The emulator is for building and testing, not for production workloads and not for security testing.
It never denies a request signed with its own key, and it does not check bucket or key policies. A test that passes locally says nothing about whether your permissions are correct or safe.
Coverage also varies widely from service to service. Some operations are implemented faithfully; others are not implemented at all, and an unimplemented operation returns an error rather than a fake success. The repository even carries a folder called “things-that-do-not-work”, where the agents file the behaviours they have found that do not yet match real AWS.
Amazon has not tested the emulator for long-running use, and it does not simulate throttling or outages.
The Engineer Who Rebuilt Four Months of Work in Two Hours
The launch came with a guest post from Swaminathan Sivasubramanian, an AWS vice president, on Werner Vogels’ blog, and it reads like a confession from someone who has watched his job change shape.
Twenty years ago, Sivasubramanian helped build Alf, one of Amazon’s earliest distributed systems — a lock service built on Paxos, the protocol that lets a group of servers agree on a single value.
Testing Alf was a project in itself. His team ran the servers inside a single program, simulated the network around them, dropped packets on purpose and used formal reasoning to find concurrency bugs. It worked, but only because AWS then had a handful of services.
That approach cannot scale to a cloud of more than 200 services. Sivasubramanian says the lesson of the emulator is that the engineer’s job has moved.
When agents write the code and check their own work, the engineer’s job is to write the specs, build the tests and design the merge gates that decide when the work is correct.
He learned that the hard way. He used Kiro to rebuild Alf’s replication engine, a job that took his team about four months the first time.
He supervised the agent for four nights before realising it had no way to check its own results. Once it had a specification and a test environment, the rebuild took about two hours.
Why This Launch Matters Beyond AWS
The emulator arrives in a year when the industry is arguing loudly about whether AI agents can be trusted with real work.
The same week, Microsoft researchers showed that reprogramming fewer than ten dormant neurons could turn an AI agent rogue, and OpenAI has built a control room that can halt a misbehaving model in 35 seconds.
Amazon’s answer is less dramatic but arguably more practical: give agents a faithful sandbox, and let them prove their work before it ever touches production.
Databricks has taken a similar direction with Genie, its always-on AI coworker that runs multi-step jobs unsupervised, and Anthropic has moved Claude into the office with spreadsheets, meetings and whiteboards.
The pattern is the same everywhere: the agent is no longer a chatbot that answers questions, it is a colleague that does jobs — and colleagues need a safe place to make mistakes.
For AWS customers, the emulator also removes a small but real friction. Students, hobbyists and developers in countries where setting up a cloud account is a hassle can now learn the AWS APIs offline, for free.
And for teams, the tests that used to cost money and take minutes can run locally, as often as they like.
What Happens Next
Amazon says it will share more about how the agents built the emulator at re:Invent, its annual cloud conference. The project is still moving fast, and the gaps in the “things-that-do-not-work” folder are the agents’ own to-do list.
Whether the emulator becomes the standard way developers test cloud code will depend on how quickly that list shrinks. But the launch itself already answers one question that has hovered over the AI coding boom all year: can agents build something large, complex and genuinely useful on their own?
According to Amazon, they just did — a local copy of the world’s biggest cloud, written entirely by the machines that will use it.
That is a strange sentence to write, and an even stranger one to read. But it is the sentence Amazon chose to publish, with the commit history to back it up. The emulator is free, it is public, and anyone with a laptop can now test whether the agents’ work holds up.
