Developers: Amazon releases software written 100% by AI agents, and nobody reviewed it

30,681 code changes, more than thirty thousand, and not a single one written by a human. That's the count I noted this morning on the GitHub page of AWS Emulator, the new free software Amazon released on Wednesday, November 11. And this isn't some lab demo we're looking at from behind glass: it's a real tool, downloadable, that thousands of developers are going to plug into their work this week. The team that launched it writes it in black and white: “Our team wrote or reviewed not a single line of this code.” Not even reviewed! Can you imagine?

A copy of Amazon's cloud that fits on your desk

A miniature cloud, on your computer

A quick reminder for those who don't live in it. AWS, short for Amazon Web Services, is Amazon's branch that rents servers and services to companies all over the world: file storage, databases, email sending, message queues... A good chunk of the websites and apps you use every day run on it without you knowing.

The problem for developers who work with AWS is testing. To check that your program knows how to put a file in Amazon's storage, you have to... really put it there, at Amazon. You need an account, a connection, and each attempt can cost a few cents. Over thousands of tests a day, it starts showing up on the bill.

AWS Emulator is a fake AWS that runs on your machine. Your program thinks it's talking to Amazon, but in reality it's talking to software installed at your place, which answers exactly as Amazon would answer. No account, no bill, no need for the Internet. It's the principle of a flight simulator: you learn to land the plane without putting the plane at risk.

Nobody wrote a line. Really nobody.

The craziest part is how it was made. It all started with a weekend. Matthew Goldberg, an Amazon engineer, gave Kiro, Amazon's in-house programming assistant, a three-step instruction: write tests based on AWS's official documentation, check that they pass on the real AWS, then build an imitation that passes the same tests. A quarter of an hour later, he had a first copy of an Amazon service. By the end of the weekend, Kiro had tackled everything else. With gaps, obviously.

To plug the gaps, Amazon set up three teams of AI agents, programs that work alone on a task from start to finish. The first writes tests and checks each one on the real AWS. The second runs those tests on the imitation and records every failure in a ticket. The third takes a ticket, looks for the cause, fixes the code. According to Amazon's post, hundreds of agents work at the same time, and thousands of fixes land every day.

No human review, but an automatic checkpoint that every fix has to get through

But not just any old way. Every fix has to get through an automatic checkpoint before entering the code: it has to compile, follow the house style rules, pass a security review done by other agents, and not break anything that was already working. If it fails, back to the sender. Amazon says it without beating around the bush: without this checkpoint, they wouldn't trust what their agents make.

I checked the figures myself on GitHub this morning: 30,681 changes, 438 service folders, one for each piece of AWS being imitated, and version 1.0.338 released last night at 10:58 p.m., Brussels time. It fixes little differences with the real AWS, one by one. This thing never sleeps.

The developer's job, Amazon-style

What interests me most, as a developer, is what Amazon takes from this about our profession. Werner Vogels, Amazon's chief technology officer, wrote it on his blog: the engineer's job is now to “give them room to work on their own”. In plain English, humans no longer write the code. They write the description of what needs to be achieved, the tests that say whether it's right, and the barriers that stop agents from doing just anything.

And he gives an example that left me stunned. An Amazon executive had rewritten by hand, years ago, a piece of the system that keeps several servers in agreement with each other. It had taken him four months. He asked Kiro to redo it. For four evenings, he watched it without any result, because the agent had no way to check its own work. With a precise description and a test environment, it was done in two hours!

That fits exactly with what I was saying when Anthropic announced that Claude was writing 90% of its own code: the real question is no longer who writes, it's who reviews. Amazon's answer is “a machine that lets nothing through”. I have loops that review my code with AI until there are zero warnings, so I understand the logic. But I always recommend the same thing: look at the code the AI produces. A checkpoint checks what it was asked to check, not what we forgot to ask it to check.

Well, does it work?

More or less, and Amazon isn't pretending otherwise. The GitHub repository contains a folder with a very honest name, “things-that-do-not-work” (the things that don't work), where all the known differences with real AWS are listed. According to the MarkTechPost website, the imitation matches real AWS on a little more than half of the tests. The documentation also warns: don't use it to test security or for production.

A simulator, not the airplane: for safety and the real takeoff, you always go through the real cloud

Developers are divided. On Hacker News, the developers' forum, one of them thinks it “looks more like a scientific experiment than a product”. Others are delighted, because the best-known competitor, LocalStack, reserved its free version this year for non-commercial use, with an account required. Here, it's free, and even released into the public domain: you can do whatever you want with it.

Two less nice details, though. The software sends usage statistics to Amazon by default, it's written on the project's homepage. And if you want to build it yourself from the code, the README asks for at least 100 GB of free space on your drive. One hundred gigs, for a fake cloud! Luckily, ready-made packages exist.

And what about you, if you're not a developer?

You're not going to install AWS Emulator, that's for sure. But your bank's app, the site where you order your groceries or your evening streaming service have a good chance of running partly on AWS. When testing becomes free and instant, developers test more, more often, and let fewer bugs through. The day your bank's app crashes a little less on the 1st of the month, some of the credit could come from there.

There's a precedent for this. In 1929, an American, Edwin Link, built a funny contraption in his father's organ factory: an airplane cockpit sitting on the ground, which tilted and turned thanks to bellows. At first, it was mainly amusement parks that bought it, as a ride. In 1934, the American army ordered six, and today no airline pilot flies without dozens of hours in a simulator. The emulator is the same for code: you train on the ground, and you only take off once it works.

The timing? For developers, it's today. For you, the effect will be indirect, slow, and impossible to measure from home. On the other hand, the way it was made will become visible much faster: if Amazon can release software of this size without writing a single line, all the big companies will want to do the same. And that changes what the development teams building your apps look like.

If you're a developer

You can skip this part if you've never programmed for AWS. Otherwise, here's how to get started, according to the project's README. The SDK is the library your program uses to talk to AWS, and the CLI is Amazon's command-line tool: both can be redirected to the emulator.

The simplest way, if you work with a coding agent: install the skill intended for it (you need AWS CLI version 2.35.0 at least), then ask it to set up the emulator.

aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1

On Linux, install the RPM or Debian package and run aws-emulator. On Windows and macOS, it runs through a Docker container. Then, a few environment variables are enough to point your SDK or CLI at the emulator instead of AWS. Everything lives in memory: when you stop it, everything disappears, which is a good thing for tests. In Rust, there is also an embedded mode, one isolated instance per test, with no network or certificate.

Before relying on it, look at each service's fidelity score on the versions page, and the issues/things-that-do-not-work/ directory. And remember to turn off telemetry if you don't want it: it's active by default, the documentation explains how to do it.

For me, the smartest part isn't the emulator, it's the judge. The agents write everything, even the tests, but every test first runs against the real AWS: the original serves as the judge of its own copy. On a project where nobody reviews anything, that's frankly the only thing that reassures me!

Sources

• Amazon, November 11, 2026: how autonomous AI agents built AWS Emulator (in English)
• Werner Vogels, All Things Distributed, November 11, 2026: AWS Emulator and the engineer's job when agents write the code (in English)
• The AWS Emulator GitHub repository, its README and its change history (in English)
• GeekWire: AWS gives developers a free local copy of its cloud, built by AI agents (in English)

Article written with the help of Claude Code, proofread and corrected by me.