Amazon lets AI agents build and run a copy of its cloud, with no human reviewing the code

Amazon Web Services has released a free local copy of its cloud, called AWS Emulator, that the company says was built, tested and is maintained almost entirely by autonomous AI agents, with no human engineer writing or reviewing the underlying code. The tool, described in a post on the AWS News Blog, lets developers run the application programming interfaces of more than 200 AWS services on a laptop, without an internet connection or an AWS bill.

The admission that no person checked the code is unusual for a company the size of Amazon, and it is stated plainly rather than played down. In a companion post on Amazon's corporate site, the AWS senior principal engineer who started the project, Matt Goldberg, wrote that "our team hasn't written or reviewed any of the code," and that the system instead relies on an automated gate of tests and adversarial security checks before anything is published. "Without this merge gate, we wouldn't trust what our agents are building," he wrote in the About Amazon account of how the agents built the emulator.

What the emulator does, and the numbers behind it

AWS Emulator runs as a local server, reachable at a fixed address on the developer's own machine, and answers the same API calls that the AWS command-line tools and software development kits send to the real cloud. According to AWS, it is built from more than 400 of the API models that specify how each AWS service behaves, and at launch it covers upwards of 200 services, including mainstays such as S3 storage, Lambda functions and DynamoDB tables. InfoWorld's coverage puts the eventual target even higher, reporting that AWS intends the tool to track all 426 AWS services over time, a figure the company has not disputed in its own materials.

The system that produces the emulator is organized into three groups of agents, running on Amazon's Bedrock AgentCore platform and coordinated through ordinary AWS developer tools, CodePipeline and CodeCommit. One group writes tests by replaying real AWS behaviour; a second group runs those tests against the emulator and files the discrepancies it finds as issues; a third group takes individual issues and fixes the code. AWS says the project runs tens of thousands of fidelity tests, with hundreds of agents working concurrently and thousands of issues resolved each day. The whole effort traces back to a weekend experiment, in which Goldberg gave the coding agent Kiro a three-step instruction — write tests from the AWS command-line tool, check them against the real service, then build an in-memory version that passes — and had a rough version of Amazon's SQS messaging service running in about fifteen minutes.

An old distributed-systems problem, revisited

The project's intellectual lineage goes back further than this year's agent boom. In a guest post on AWS chief technology officer Werner Vogels' blog, All Things Distributed, AWS's head of agentic AI, Swami Sivasubramanian, recalled a roughly twenty-year-old internal locking service called Alf, whose correctness the original team could only establish through painstaking simulation and formal methods, because large-scale testing of distributed failures was too costly to run on demand. Sivasubramanian wrote that he later tried rebuilding Alf's replication engine with an AI agent: left without a specification or a way to check its own work, the agent produced nothing usable after four nights of effort; given both, it finished in about two hours. That contrast, he argued, is the actual lesson of AWS Emulator — not that agents can write code quickly, but that they can only be trusted to write it correctly when engineers have first built a rigorous way to grade the result. "Software quality in the AI era depends on the guardrails that engineers design around agents," he wrote, describing engineers' new role as "systems orchestrators" rather than authors of most of the code themselves.

Who stands to use it, and its limits

The emulator is aimed squarely at developers and, increasingly, at the coding agents they supervise. By AWS's account, pointing an agent such as Kiro or Claude Code at a local emulator rather than live infrastructure lets it create resources, check the result and iterate without the delay or expense of provisioning anything in the real cloud, or the risk of leaving stray billable resources behind. Analysts quoted by InfoWorld made a similar case from the enterprise side: Broadcom's Advait Patel said moving an agent's write-run-fix loop onto a laptop "cuts each cycle from minutes to seconds," while HFS Research's Ashish Chaturvedi said a local sandbox could ease the concerns of chief information officers wary of letting agents loose on production infrastructure before their code has been tested.

That reassurance has real limits, though, which AWS states in its own documentation rather than leaving to outside critics. The emulator does not evaluate identity and access permissions the way the real AWS does, so a request the live service would deny might quietly succeed inside the emulator. It behaves as a single account with no cross-region or cross-account behaviour, and its accuracy varies service by service. IDC analyst Devin Pratt, also cited by InfoWorld, went further, warning that the tool does not sandbox the code it runs, so a function still configured with real production credentials could reach live AWS resources even while nominally under test, and that treating a passing local run as proof of production readiness risks "false confidence."

A skeptical reception alongside the applause

"It's remarkable that AWS built this twin completely with agents."

Constellation Research analyst Holger Mueller, who described the release as effectively "a digital twin of its public cloud," called that achievement remarkable in comments reported by SiliconANGLE, while noting the project's scale as much as its method. Trade coverage elsewhere was more clinical about Amazon's motive. The Register pointed out that the emulator "doesn't replicate anywhere near all the features of the Amazonian cloud" and suggested Amazon's "intent appears, as ever, to encourage more use of its cloud" by making it easier to build applications that ultimately deploy there. The emulator also enters a field where smaller, human-built alternatives already exist; AWS and outside coverage both note that third-party emulators such as LocalStack have long covered only a fraction of AWS's services and tend to fall behind as those services change, which AWS casts as the gap its agent-built, continuously regenerated version is meant to close.

AWS Emulator is released under a public-domain CC0 licence, with its source code, commit history and a running public list of which AWS behaviours it does and does not yet replicate posted on GitHub. AWS has not said when, or whether, a human engineer will begin reviewing the code the agents produce, nor has it set out a timetable for closing gaps such as access-policy enforcement. For now, the company is treating the absence of human review as the point of the exercise rather than a gap to be closed, a stance that leaves the tool's longer-term trustworthiness to be tested by the thousands of developers now being invited to point their own AI agents at it.