AWS releases an emulator no human wrote or reviewed

AWS shipped software no human wrote. Read the merge gate first.

On Nov. 11 AWS released AWS Emulator, a local emulator you run on your own machine to build and test AWS applications. It says autonomous agents built it.

The team says it wrote and reviewed none of it

"Our team hasn't written or reviewed any of the code," writes Matthew Goldberg, a senior principal engineer at AWS, in the company's post.

The project started as a weekend experiment, he says. Goldberg prompted Kiro, an AI coding tool, which produced a first version of Amazon SQS, the queue service, in about 15 minutes, then built more of AWS over the weekend. The team was using it to test its own software the following Monday.

Today, per the post, hundreds of agents work on the codebase at once, split into three teams:

• Test writers turn AWS's public API models into fidelity tests and check each one against real AWS.
• Issue finders run those tests against the emulator and file each failure.
• Fixers take one issue each and merge a change through a gate that covers build, review, security and fidelity.

AWS says the suite holds tens of thousands of fidelity tests and that thousands of issues are fixed every day.

The emulator is released under a Creative Commons CC0 dedication. The source is on GitHub, with the fidelity tests in a separate repository, and AWS offers a downloadable binary.

The humans built the merge gate, and that's what to copy

Yes, "no human reviewed the code" sounds like a liability. Read what the humans did instead.

They built the guardrails the agents work inside: the three-team split and the merge gate. AWS's public API models serve as the spec and the real AWS cloud as the reference, per the post. "Without this merge gate, we wouldn't trust what our agents are building," Goldberg writes.

That is the pattern worth stealing. The agents never grade their own homework. One team writes tests against the real service, another finds failures, a third fixes them, and nothing merges without passing the gate. Real AWS is the answer key.

This is what agentic coding at scale looks like when it works: a multi-agent system with a referee that can't be talked out of a failing test.

It also tells you where it works. An emulator has a perfect oracle, because the real service exists and every behavior can be checked against it. Most of your code has no such answer key.

What you can do with it today

If you build on AWS, you can test locally against the emulator instead of a live account. Start with SQS, the first service the agents built, and check what else works before you depend on it.

The repository is unusually honest about that. Its issues/things-that-now-work and issues/things-that-do-not-work directories record the agents' progress, per the post. Read the second one first.

If you run coding agents on your own projects, borrow the structure:

• Write tests against a source of truth the agent can't edit.
• Separate the agents that find problems from the ones that fix them.
• Make the merge gate strict, automatic and outside the agents' reach.

Watch the do-not-work list shrink

The number to follow is fidelity: how much of real AWS behavior the emulator matches, service by service. The test suite is public, so you can check it yourself.

Then watch whether other teams publish their gates, not just their demos.

Trust the gate. Verify the list.