# AWS let autonomous agents write an entire cloud emulator

AWS says thousands of agents collectively wrote and maintain the code, while hundreds can work concurrently. Its team says people did not write or review any line. People designed the specifications, fidelity tests and merge gates that constrain the work.[1][2]

AWS released AWS Emulator on November 11, 2026. The free local tool accepts AWS API calls without an AWS account, so developers and coding agents can test applications on a workstation or in CI before using real cloud resources.[1][2][3]

AWS says autonomous agents wrote every line and that its team did not review the code. Three agent groups write behavioral tests, find differences from real AWS and fix one issue at a time. Automated build, security, coding-standard and regression checks control what reaches the release branch.[1]

The result is a useful product and a strong case study, but it does not remove human engineering responsibility. AWS documents incomplete fidelity and warns users not to test permissions, policies or other security controls in the emulator. Teams still need tests against real AWS before production.[2][4][5]

## What AWS released

[AWS announced [1]](https://www.aboutamazon.com/news/aws/how-autonomous-ai-agents-built-aws-emulator) a local emulator that serves an AWS-compatible API endpoint. Developers can point the AWS CLI or an SDK at the local process and test with emulated resources instead of calling the cloud.

AWS documentation says the tool runs on Linux from Debian or RPM packages, on macOS and Windows through Docker, and inside Rust tests through an embedded mode. It does not require an AWS account and has no additional service fee.[2][3]

The source is public. Most code uses the CC0 public-domain dedication, while the vendor directory uses Apache License 2.0. AWS publishes release-specific fidelity scores and keeps known gaps in the repository.[2]

## How the autonomous build system works

AWS divided the work among three agent groups. Test-writing agents derive scenarios from public API models and verify each scenario against real AWS. Issue-finding agents replay those scenarios against the emulator, and fixing agents take one identified difference at a time.[1]

AWS says hundreds of agents work concurrently and fix thousands of issues per day. Before a change merges, automated checks cover compilation, coding standards, security and regression against the fidelity suite.[1]

The public evaluation repository says every included fidelity test was verified against at least two sandboxed AWS accounts. It also states that untested behavior remains unverified, even when the emulator appears to handle it correctly.[5]

[Amazon CTO Werner Vogels describes [6]](https://www.allthingsdistributed.com/2026/11/aws-emulator-and-the-engineers-job-when-agents-write-the-code.html) the emulator as a test environment for coding agents. AWS engineers still chose the architecture, formal boundaries, reference behavior and acceptance gates that made independent work possible.

## What no human code review means here

AWS makes a narrow claim: its team neither wrote nor reviewed the emulator code. That does not mean people supplied no engineering judgment. People selected the problem, chose AWS API models as the specification, approved real AWS as the reference, designed the agent roles and defined the merge checks.[1]

The distinction matters because the evidence comes from executable behavior rather than a person reading every diff. A test can prove that a named scenario matches the reference, while it cannot prove that untested behavior is correct or that the implementation is easy to maintain.[2][5]

Independent reports from SiliconANGLE and InfoWorld confirmed the release and repeated the agent-authorship claim, but both reports attribute the no-review statement to AWS. The public repository and tests let developers inspect the resulting artifacts, while they do not independently prove how every private build step ran.[7][8]

## Why this matters for coding-agent teams

AWS gave its agents a machine-readable specification, a working reference and fast pass-or-fail feedback. Many coding-agent projects have only a prose request and a broad repository, which leaves more room for misunderstood requirements and changes that cannot be verified.[1][5]

Teams can adapt the pattern without running thousands of agents. One agent can write a characterization test against the current system, a second can identify a single mismatch, and a third can propose a fix that must pass an independent gate.[1][5]

The pattern fits APIs, parsers, compatibility layers and migration tools especially well because those systems often have observable reference behavior. Product judgment, accessibility, security policy and ambiguous user needs still require evidence that goes beyond matching an existing implementation.[1][4][5]

## A Learnetto trial for your own project

The following checklist adapts AWS's specification, reference-test and merge-gate pattern for teams that require human review of agent changes. It describes Learnetto's recommended trial, rather than AWS's exact process.[1][5]

- Choose one bounded compatibility task with a stable reference, such as a parser, API client or command-line workflow.[1]
- Write down the allowed files, commands, network destinations, credentials, time budget and stopping conditions before the agent starts.
- Capture representative behavior from the reference system, including successful results, validation errors, state changes and cleanup.[5]
- Keep test authorship separate from the fixing task so the same agent does not redefine success after seeing a failure.[1][5]
- Give each fixing run one issue with a reproducible failing test instead of a broad instruction to improve the system.[1]
- Require compilation, focused tests, regression tests, dependency checks and secret scanning. Add human review of the exact diff before your team merges it. AWS says its own gate used automated checks and no human code review.[1]
- Measure accepted fixes, rejected changes, regressions, elapsed time, compute cost and human correction time.
- Expand only when the gate catches seeded failures and the accepted changes remain understandable to the team.

## How to try AWS Emulator without mistaking it for AWS

Start with a non-production project and list the AWS operations it calls. AWS provides an agent skill and a manual process for matching those operations to public fidelity tests and release scores.[5][9]

Run the same important workflow against the emulator and a sandboxed AWS account. Compare return values, errors, state transitions and asynchronous behavior, then record any operation for which the public suite has no test.[3][5]

Keep credentials and production data out of the emulator. It listens on localhost by default and creates run-specific credentials, but the operator controls where it runs, what data enters it and whether its endpoint becomes reachable from another machine.[4]

Pin a release in CI. The project changes rapidly, so an unpinned build can change behavior between runs and make a regression difficult to reproduce.[2]

## Security limits AWS states plainly

AWS warns users not to use the emulator to test application security. Passing local tests does not show that IAM policies, permission boundaries, bucket policies, KMS policies or cross-account controls are safe.[4]

The emulator can accept requests that real AWS would deny, and real AWS can accept requests that the emulator rejects. Teams must therefore test security settings and the complete application against real AWS before production.[4]

Telemetry is enabled by default, although AWS says requests, responses, code, credentials and personal data are excluded. Users can disable telemetry with a command option, an environment variable, a local configuration file or an embedded configuration setting.[10]

## Limits and open questions

AWS has not published an independent audit of the complete agent pipeline. Its public artifacts support inspection of released code, tests, commit history and known issues, while the authorship and private orchestration details remain company claims.[1][2][5]

Fidelity varies by service and release. The repository includes stubs and known behavioral differences, and AWS tells users to consult release scores for the operations their project needs.[2][5]

AWS says the emulator does not support calls across accounts or Regions and can disagree with AWS on authorization outcomes. Public fidelity tests do not cover every behavior. Teams should therefore treat it as an early feedback layer rather than the final production gate.[4][5][9]

AWS does not accept pull requests to the main emulator repository. Developers can report gaps, inspect the backlog and run the published evaluation suite, but AWS's agent system controls implementation changes.[2][5]

## Frequently asked questions

- Did AI agents really write all the code?[1][2] AWS says autonomous agents wrote every line and that its team did not review the code. The public repository shows agent-attributed commits, but no independent audit of the private orchestration has been published.[1][2]
- Can AWS Emulator replace a test account?[4][5][9] No. It can provide fast local feedback, but AWS requires real-cloud testing for security and recommends comparing uncovered behavior with AWS.[3][4][5]
- Is the tool free?[2][3] AWS says the emulator has no additional service fee. Real AWS resources still incur charges when an application is deployed or when teams run comparison tests.[2][3]
- Can I use it in production?[2][3] No. AWS describes it as a development and testing tool and tells users not to run production workloads on it.[2][3]
- Does it work with coding agents?[2][3][9] Yes. AWS provides an emulator skill for coding agents, and ordinary tools can use the local endpoint through the AWS CLI or SDK configuration.[2][3]
- What should a small team copy from AWS's approach?[1][5] Start with one bounded task, independently verified behavior and an automated merge gate. Add concurrency only after the gate rejects bad changes reliably.[1][5]

## Sources

- [[1] AWS: How we built the agents that built AWS Emulator](https://www.aboutamazon.com/news/aws/how-autonomous-ai-agents-built-aws-emulator)
- [[2] AWS Emulator source repository and README](https://github.com/aws/aws-emulator)
- [[3] AWS Emulator documentation](https://docs.aws.amazon.com/emulator/latest/userguide/what-is-service.html)
- [[4] AWS Emulator security guidance](https://docs.aws.amazon.com/emulator/latest/userguide/security.html)
- [[5] AWS Emulator evaluation suite](https://github.com/aws/aws-emulator-evaluation-suite)
- [[6] All Things Distributed: AWS Emulator and the engineer's job](https://www.allthingsdistributed.com/2026/11/aws-emulator-and-the-engineers-job-when-agents-write-the-code.html)
- [[7] SiliconANGLE: AWS Emulator release coverage](https://siliconangle.com/2026/11/11/amazons-open-source-aws-emulator-lets-developers-validate-their-code-locally-without-the-cloud)
- [[8] InfoWorld: AWS Emulator release and limits](https://www.infoworld.com/article/4247383/aws-unveils-local-emulator-service-to-help-enterprises-accelerate-app-development-and-testing.html)
- [[9] AWS: Checking whether your project works with AWS Emulator](https://docs.aws.amazon.com/emulator/latest/userguide/check-project.html)
- [[10] AWS Emulator telemetry guidance](https://docs.aws.amazon.com/emulator/latest/userguide/telemetry.html)