Amazon's AWS Emulator was written entirely by AI agents

An emulator is a program that pretends to be something else. This one pretends to be Amazon Web Services, or AWS, the huge rental cloud that many apps run on.

When you build an app that stores files or sends messages in the cloud, you need somewhere to test it. Testing on the real cloud costs money and needs an internet connection. An emulator gives you a practice version on your own computer.

In real life Think of a flight simulator. The pilot practices takeoffs and crashes nothing. A developer can run their app against AWS Emulator, break things freely, and no real cloud bill appears.

The GitHub repository describes it as a local emulator of the AWS APIs. An API is a doorway that lets one program ask another program to do something. The emulator runs as a local web address, and you point your tools at it instead of at Amazon.

The project is open for anyone to download. Here is what the repository lists:

• License: CC0 1.0, a public dedication, with the code in its vendor folder under the Apache License 2.0.
• Language: Rust, with one crate (a bundle of code) for each AWS service.
• Linux: install from an RPM or Debian package.
• Windows and macOS: run it in Docker, a tool that packs software into a sealed box.
• Embedded mode: add it to a Rust project as a test dependency, so tests run in the same process.

There are limits. Building it from source needs a Rust toolchain, a C compiler, about 100 GB of disk space and a multi-core machine. The repository also says it is not meant for production workloads or security testing.

The catch: an emulator is only as good as its copy of the real thing. The repository says fidelity scores vary by service, and they are published with each release.

Amazon's answer is: agents. An AI agent is an AI program that does a task on its own, step by step, instead of only answering a question.

Amazon says thousands of autonomous agents write tests, find issues and fix code without human review. Hundreds of them work in the same codebase at once, and thousands of issues are fixed every day.

The team behind it says it has written none of the code and reviewed none of it.

The author of Amazon's post says the idea came from a lightbulb moment earlier this year. Researchers at Anthropic showed that agents can build a C compiler on their own. A compiler is a program that turns code people write into code a computer can run.

Anthropic's write-up, published February 5, 2026, gives the scale:

• Agents: 16 working in parallel.
• Sessions: nearly 2,000 Claude Code sessions over two weeks.
• Cost: just under $20,000.
• Result: a 100,000-line compiler that built Linux 6.9 on x86, ARM and RISC-V.

The AWS author saw that the same trick could work for the cloud. If you have a clear spec and a reference to copy, agents can build a faithful copy. AWS has both: its published API models are the spec, and the real AWS cloud is the reference.

So the author gave Kiro, Amazon's AI coding agent, a short list of instructions:

• Write tests based on the AWS command line tool.
• Iterate on those tests until they pass against real AWS.
• Build an in-memory version that passes the same tests.

Kiro came back after 15 minutes with a passable first version of Amazon SQS, a message queue service. The author refined the prompt and had Kiro build the rest of the emulator over a weekend. It had gaps, but the team started using it to test their own software the following Monday.

A weekend demo is not a product. The author writes that it is tempting to believe AI can build anything, but that shipping something customers can trust still takes serious engineering. In this case, that meant building guardrails, rules and checks that keep the agents inside the lines.

The author's picture for this is a coloring book. A well-defined area to fill in lets the larger picture come together, and agents need the same thing.

Amazon splits the job into three teams of agents. It says agents do better on small, bounded tasks.

• The test team: writes tests that measure how closely the emulator matches real AWS. Each test is a real-world scenario. For SQS, one test creates a queue, sends a message, receives it, acknowledges it and deletes the queue.
• The finder team: replays those tests against the emulator and files an issue for each one that fails. Agents are told to group failures that share a root cause.
• The fixer team: each agent takes one issue, finds the cause and edits the code until it is fixed.

The tests come first, because they give the agents a clear goal. Agents write them from the public AWS API models and check each one against real AWS before submitting it. Amazon has tens of thousands of fidelity tests across AWS, and the suite keeps growing. Because the tests can be rerun again and again without calling AWS, they cost little to reuse.

At the start, the repository was an empty web server. It could receive requests for the 438 AWS API models but did nothing with them. The first issues were as simple as "build a first version of Amazon SQS."

Every fix has to pass a merge gate, a checkpoint before code joins the main version. Amazon says the gate:

• blocks changes that do not compile;
• uses review agents to check coding standards;
• checks that the code is secure;
• checks that the change did not make the emulator less faithful to AWS.

If any check fails, the change goes back to the agent for rework. If all pass, it is merged. The author says that without this gate, the team would not trust what its agents build, so the team works hard to make it fast and reliable.

Why it matters: the gate is the real story. The agents are fast, but the checks are what turn fast into trustworthy.

After merging, changes go through a release pipeline built on AWS developer tools, with AWS CodeCommit as the agents' main code repository. Commits stack up, get built and retested, and then move to a release branch. The team packages the emulator as a binary you can download.

Only at the end of that process does the code also go to GitHub. Every issue the agents filed is in the repository. Fixed ones sit in a folder called "issues/things-that-now-work," and open ones are in "issues/things-that-do-not-work."

The author says there are fascinating things to find. One favorite came from an earlier version: the agents decided to build their own Python interpreter to support AWS Lambda functions. The team has since told them to reuse existing libraries.

Amazon says this history is why it chose to release the code as a public dedication under CC0. It also says this is the first in a series of posts on how the multi-agent workflow works, how fidelity is measured and how quality and security are kept high.

Amazon has not said which AI models run the agents today. It has also not published fidelity numbers in its post, though it says scores come with each release.

The more interesting question is whether others copy the recipe. The pattern is simple: a clear spec, a real reference to compare against, tests that can be rerun, and a gate that blocks bad work. Any project with those four pieces could try it.

• If you build on AWS: you can test locally for free, with no account and no cloud bill, though the tool is not for production.
• If you write software: the recipe is public. Look at the repository to see how agents were guided, and what they got wrong along the way.
• If you are just curious: this is a real example of agents doing a whole project, with the tests doing the supervising.
• If you want to check it: every issue the agents filed is open to read on GitHub.