Agents Wrote All of AWS Emulator’s 200+ Services. What’s the Engineer’s Job Now?

Agents wrote all of the code in AWS Emulator, a local copy of more than 200 AWS services that is free to use (“no additional service fee”, per AWS), and every change passed a merge gate that includes security agents doing adversarial reviews, AWS said at launch on 11 Nov 2026. The claim puts a hard question to every team merging agent-written code, which is what the engineer’s job becomes when people no longer write or read each line.

TL;DR

• AWS says its team wrote and reviewed none of AWS Emulator’s code. Agents built more than 200 services from more than 400 public API models, and a merge gate of checks, a code reviewer agent and several security agents decided what merged, by AWS’s account.
• AWS credits a written spec and a live answer key. The public API models describe each service, and real AWS confirms each test. Most product code has neither.
• The engineer’s job moves to the gate. Engineers write the rules, define what correct means for each change and decide which findings need a person, as Qodo’s AI code review academy covers for everyday teams.
• Qodo reviews every everyday pull request (PR) against the team’s written rules. Qodo checks each PR against REVIEW.md, organization instructions and the linked ticket, labels security findings by severity and keeps a record of what was resolved, so teams merge agent-generated code sooner with fewer rollbacks.

Agents Write Code Quicker Than Teams Can Check It

Checking agent-written code is the step that holds delivery back. Reviewing and validating AI-generated code is the main delivery constraint for 25.8% of developers and 26.0% of engineering leaders, in a 2026 survey of 500 US developers and 300 US engineering leaders behind Qodo’s AI code review guide. In the same survey, 36.4% of developers say AI-generated code takes the same review time with more mental effort.

A coding agent works in a loop: write the code, run it, read the result, change the code. The loop only helps when the agent has something trustworthy to check against, such as a test environment that behaves like production or a written rule. Without one, the agent reports “done” and a person carries the checking.

AWS hit the test-environment problem and the checking problem at once. An application that calls AWS needs a test environment for each of the services it uses, and building environments for more than 200 services by hand would take years, AWS says. AWS Emulator answers the test-environment problem, and the way AWS built it answers the checking problem.

How AWS Says Agents Built AWS Emulator

The story starts twenty years ago with Alf, a Paxos-based lock service that still powers systems such as S3 and DynamoDB. Swami Sivasubramanian, AWS vice president of agentic AI and emerging tech, tells it in a guest post on All Things Distributed, the blog of Amazon CTO Werner Vogels. His team tested Alf by simulating its whole environment inside one program.

A hand-built simulation worked when AWS had a handful of services. Matt Goldberg, a Senior Principal Engineer on the AWS Developer Tools team, bet that agents could build the environments themselves given a written description of each service and the real service to check against. AWS had both, in the public API models written in AWS’s Smithy format and in the AWS cloud as the answer key.

Goldberg tested the idea over a weekend. He gave Kiro, AWS’s coding agent, a three-step prompt: write tests from the AWS CLI, iterate until they pass against real AWS, then build an in-memory version that passes the same tests. Kiro returned a passable Amazon SQS emulator in about 15 minutes and a rough version of the rest of AWS by Monday, Goldberg writes in AWS’s launch post.

Turning the prototype into a product took a system of agents and guardrails.

“The emulator was written entirely by autonomous agents. Our team hasn’t written or reviewed any of the code. Matt Goldberg, Senior Principal Engineer at AWS, AWS launch post, 11 Nov 2026”

Three teams of agents do the work, according to Goldberg. One team writes fidelity tests, real customer scenarios such as creating a queue and sending a message, and verifies each against real AWS. A second team replays the tests against the emulator and files issues for the failing tests, grouping failures that share a root cause. A third team takes one issue per agent and edits the code until the issue is fixed.

Each fix then meets the merge gate. The gate stops changes that don’t compile, and agents check each change against coding standards, for security and for fidelity regressions. A change that fails any check goes back for rework, and one that passes every check merges. An independent security agent reviews each change adversarially during the fix and again in the release pipeline, the AWS News Blog adds.

The AWS Emulator repository holds every issue the agents filed, with open gaps under issues/things-that-do-not-work/ and fixed ones under issues/things-that-now-work/.

Why AWS Emulator Matters: AWS Dropped Line-by-Line Review and Kept a Gate

AWS’s claim sounds like the end of code review, yet AWS’s own posts describe every change passing a bench of checks and reviewer agents.

“Without this merge gate, we wouldn’t trust what our agents are building. Matt Goldberg, Senior Principal Engineer at AWS, AWS launch post, 11 Nov 2026”

The tension sits in Goldberg’s sentence. Human review left the line-by-line level, and the review function grew into bounded tasks, an unambiguous goal in the fidelity tests and several reviewers with different jobs between each change and mainline. Sivasubramanian supervised Kiro for four nights on a rebuild of Alf’s replication engine, a four-month job the first time, before he saw the agent had no way to check its results. With a spec and a test environment, the rebuild took about two hours, he writes.

AWS’s own docs mark the edges of the result. The emulator does not evaluate IAM policies the way AWS does, so a request AWS would deny might succeed locally, and AWS tells users not to use the emulator to test security. The emulator does not yet simulate throttling, outages or regional differences, an IDC analyst told InfoWorld, as GeekWire reported.

AWS showed that agents can build a large, well-specified system when the gate is strong. AWS did not show that every codebase has the inputs that made the gate strong, and most do not.

What Breaks When Everyday Code Has No AWS-Style Gate

AWS Emulator had two advantages few products share, a machine-readable spec for every operation and a live system that answers every test. A payments service or an internal data pipeline has neither. Four things break when teams copy AWS’s working model, agents writing and people stepping back, without AWS’s inputs.

1. The rules live in people’s heads. AWS’s agents had the Smithy models and coding standards to check against. Most teams’ standards already exist in wikis, rules files and senior engineers’ heads, but an agent never sees most of them, and review can’t check what nobody wrote down.
2. Intent sits outside the diff. A fidelity test tells AWS’s agents exactly what correct means. On a product team, correct means what the ticket asked for, and 13.2% of developers name understanding whether code matches its intent as their greatest AI code review challenge in the same 2026 survey.
3. Security findings look like every other comment. AWS gave security its own adversarial reviewers. On a typical PR, a missing authorization check sits in the same comment list as a naming nit.
4. The agent’s “done” becomes the record. AWS keeps a public record of each issue, because every issue is a file in the repository. Most teams have no record outside the coding agent showing which findings were fixed, dismissed or left open across repositories.

Each break has a counterpart in AWS’s design, and each counterpart is something an engineer built.

What Is the Engineer’s Job Now? Build the Gate and Decide What It Checks

“When agents write the code and check their own work, the engineer’s job is to give them room to work on their own and to build the specs, tests, and merge gates that decide when that work is correct. Swami Sivasubramanian, Vice President of Agentic AI and Emerging Tech at AWS, guest post on All Things Distributed, 11 Nov 2026”

For an everyday team, the review side of that work means four jobs, one for each break.

1. Write the rules down per repository and across the organization, so review has a standard to check against.
2. Bring the ticket into the review, so each change is checked against what it was meant to do.
3. Rank findings by severity, so security and correctness issues reach a person first and style notes wait in the summary.
4. Keep the record outside the agent, showing which findings were resolved, dismissed or left open.

A short list of expensive-to-fix rules, such as architecture, security and forbidden patterns, belongs in the coding agent’s instructions, and a separate review agent checks every change against the full standard. The separation matters as much as the rules. AWS’s gate uses reviewers that are not the agent that wrote the fix, and the system that writes the code should not be the only system that checks it.

A bespoke gate like AWS’s takes a team, a pipeline and a spec most products don’t have. Everyday teams need independent review on the PRs they already open, across every repository and coding agent.

How Qodo Reviews Everyday PRs Against the Team’s Rules

Qodo, the AI Code Review Platform, is the quality and governance layer that checks agent output before it reaches production. Qodo works at the PR layer, next to the tests, emulators and build checks a team already runs, such as a local AWS emulator. Tests and emulators check how code behaves. Qodo checks each change, from developers or any coding agent, against the team’s written rules and linked ticket, and keeps the record.

REVIEW.md and Custom Instructions Write the Review Rules

REVIEW.md is a file at the root of a repository that tells Qodo’s review agents what to flag and how to prioritize findings on every PR. Teams write their review rules in plain Markdown, such as “IAM policies name specific actions and resources,” and the next PR review reflects any update.

As of 5 Nov 2026, REVIEW.md instructions are on by default for Qodo SaaS workspaces, and single-tenant and on-premises teams turn them on in the Qodo portal. Custom instructions in the portal add organization-wide guidance for the Issue finding agent and the Compliance agent. Enterprise engineering teams get one written standard across many repositories and coding agents.

Ticket Context Checks Each Change Against Its Intent

Qodo reads the ticket linked to a PR and checks how well the changes match the stated intent, the role a fidelity test plays at AWS. A PR that misses part of the ticket gets a requirement-gap finding. Qodo finds the ticket through a link in the PR description or a key in the branch name, and works with Jira, Linear, Azure DevOps, GitHub Issues and other tools in its ticket context guide.

Security and Severity Labels Put the Dangerous Findings in Front of People

Qodo labels every finding High, Medium or Low and tags its quality impact, including Security for issues that could expose vulnerabilities or sensitive data. High covers issues to address before merging, such as security or compliance violations and critical correctness issues. By default, every severity appears both inline and in the summary, and comment routing in the Qodo portal lets admins send each severity to inline comments, the summary or both.

Routing High findings inline and Medium and Low findings to the summary gives reviewers a short list on the code. PR review stays low-noise because people read every comment. High-velocity teams keep the coding agents they already use and get every PR checked, with setup in about 5 minutes on GitHub or Bitbucket Cloud and no new process.

Resolved Findings, Review Resolver and Analytics Keep the Record

Each time Qodo reviews a new commit, Qodo re-checks every open finding against the changes since the finding was raised and marks each one Resolved, Dismissed or Outdated. The record comes from Qodo’s review, outside the coding agent’s own report.

Review Resolver, an Agentic Toolbox skill, lets a coding agent pull Qodo’s findings from an open PR and fix the ones a developer picks, with an explicit outcome for each. Review Resolver runs in Kiro through Qodo’s power for Kiro, in Claude Code and Codex through plugins, and over the CLI or MCP. Qodo’s code review analytics shows admins which high-severity and security findings remain unaddressed, by repository and PR author.

Where Everyday PR Review Catches What Tests Miss: An Example

The example is an illustrative composite built from common patterns in agent-written PRs and describes no real customer.

An IAM policy that passed every local test

A platform team’s coding agent added an export job that writes reports to an S3 bucket. The agent tested against a local emulator, every test passed, and the PR description said the work was done. The new IAM policy granted s3:* on every resource. Tests check that the job works, and a wide grant works.

The team’s REVIEW.md requires IAM policies to name specific actions and resources, as high severity. With comment routing configured as in step 5, Qodo raised a High finding with the Security label inline, and two Low findings went to the summary. The developer had the agent fix the finding through Review Resolver, and Qodo marked it Resolved on the next commit.

Hands-On: Turn On Qodo Review for Agent PRs

The steps follow Qodo’s docs as of 12 Nov 2026. The rule text is an example, not a Qodo default.

1. Install Qodo on your Git provider. Installation takes about 5 minutes on GitHub and on Bitbucket Cloud, and around 5 to 10 minutes on GitLab and Azure DevOps. Reviews then run automatically when a PR is opened, reopened or marked ready for review.
2. Write the review rules in REVIEW.md at the repository root.

# REVIEW.md

## Rules every change must follow

- IAM policies name specific actions and resources. No "*" actions or resources.
- Credentials, tokens and presigned URLs never reach logs, error messages or analytics events.
- Queue and event consumers are idempotent: processing the same message twice has the same effect as once.
- Changes under `infra/prod/` or `vendor/` need a linked ticket that asks for them.

Treat a violation of these rules as high severity.

3. Add organization-wide guidance. In the Qodo portal, go to Configurations, then Custom instructions, add the rules every repository shares for the Compliance agent and the Issue finding agent, and click Save.
4. Connect your ticketing tool. For Jira Cloud, go to the Qodo Integrations page, click Connect Jira Cloud and click Accept, as Qodo’s Jira guide describes, and add jira_base_url under [jira] in the configuration file so branch names and short ticket IDs resolve. Link each ticket in the PR description, or put the key at the start of the branch name or right after a slash, such as feature/PROJ-123-order-consumer.
5. Route findings by severity. In the Qodo portal, go to Configurations > Display > Comment routing, send High to Inline & Summary and Medium and Low to Summary, and click Save changes, or pick the Balanced display mode, which applies the same routing.
6. Resolve findings from the coding agent. Open Kiro Powers, search for Qodo under Browse Powers, click Open in Kiro and follow the prompts. Then ask the agent to resolve the findings you choose.

Resolve the security findings from my pull request.

7. Read the record. As an admin, open Analytics in the Qodo portal, choose Last 30 days, filter by Type: Security and Severity: High, and break the data down by repository.

Summary

AWS says agents wrote every line of AWS Emulator, a local copy of more than 200 AWS services, and that a merge gate of build checks, a code reviewer agent and several security agents decided what merged.

The engineer’s job moves to building and owning the checks. Qodo reviews everyday PRs against the team’s rules and keeps the record outside the coding agent. AWS’s gate and Qodo are complementary layers, and neither replaces the other.

Teams merge agent-generated code sooner with fewer rollbacks. Qodo’s code review best practices, its look at unfinished agent work and its guide to where code rules should live cover the wider picture.

FAQs

Did AI agents really write all of AWS Emulator’s code?

AWS says so, in Matt Goldberg’s launch post, and his team wrote and reviewed none of the code. Recent commits in the public GitHub history are authored by agents, and AWS reports that every change passed a merge gate before it merged.

What is a merge gate?

A merge gate is the group of checks a change must pass before it enters the main codebase. In AWS Emulator, the gate checks that the code compiles, follows coding standards, passes security-agent reviews and does not regress fidelity tests, by AWS’s account. Qodo reviews everyday PRs against REVIEW.md, organization instructions and the linked ticket, so people see the findings that matter before they decide to merge.

Does AWS Emulator mean code review is no longer needed?

No. AWS’s team trusted the code because every change passed reviewer and security agents, by AWS’s account. Most product code has no API-model spec or live answer key, so Qodo reviews each PR against the team’s rules and ticket as the everyday review layer.