---
title: 'In the News: November 11, 2026 (Extra 2)'
description: 'AWS says agents wrote its new local AWS emulator with no human-written or human-reviewed code, and describes the merge gate it trusts instead.'
canonical_url: 'https://darkfactory.dev/news/2026-11-11-extra-2'
markdown_url: 'https://darkfactory.dev/news/2026-11-11-extra-2.md'
collection: news
date_published: '2026-11-11T16:08:00-05:00'
date_modified: '2026-11-11T16:08:00-05:00'
---

# In the News: November 11, 2026 (Extra 2)


AWS released a local emulator of its own APIs today and says agents wrote all of it, with no human writing or reviewing the code. The launch posts describe the test suite and merge gate that stand in for review. Google also shipped a low-cost endpoint for the routing and policy decisions a harness makes.

## 1. AWS ships an emulator it says no human wrote or reviewed

**[AWS Emulator: a local emulator built 100% by autonomous AI agents](https://www.aboutamazon.com/news/aws/how-autonomous-ai-agents-built-aws-emulator)** · Matthew Goldberg, Sr. Principal Engineer, AWS · About Amazon, November 11, 2026

AWS Emulator runs on a developer's machine and answers AWS API calls so software can be tested without an AWS account. Goldberg writes: "The emulator was written entirely by autonomous agents. Our team hasn't written or reviewed any of the code." He describes three teams of agents. The first writes fidelity tests from the public AWS API models and verifies each one against real AWS before submitting it. The post puts the suite at "tens of thousands" of tests. The second team replays those tests against the emulator and files issues for the failing tests, grouping failures that may share a root cause. In the third, one agent takes one issue, fixes it, and submits the change to a merge gate. The gate rejects code that does not compile, runs review agents for coding standards and security, and checks that fidelity did not regress. A failed change goes back to its agent for rework. Goldberg says hundreds of agents work on the codebase at once and fix thousands of issues a day, and adds: "Without this merge gate, we wouldn't trust what our agents are building."

The [repository](https://github.com/aws/aws-emulator) is public under CC0 and showed 29,684 commits when we looked on the afternoon of November 11. Its README says the emulator is for building and testing, not for production workloads or security testing, and that the repository does not take pull requests. Open and fixed issues sit in two folders, `issues/things-that-do-not-work` and `issues/things-that-now-work`. The repository's `AGENTS.md` marks the `vendor/` directory as an "agent-immutable framework".

In a [companion post](https://www.allthingsdistributed.com/2026/11/aws-emulator-and-the-engineers-job-when-agents-write-the-code.html) on Werner Vogels's All Things Distributed, AWS's Swami Sivasubramanian says the engineer's job is now "to build the specs, tests, and merge gates that decide when that work is correct." He gives one comparison from his own work. He used Kiro to rebuild a replication engine that first took about four months to write, and supervised the agent for four nights before he saw that "it had no way to check its results." With a spec and a test environment, he writes, "the rebuild took about two hours." The [Hacker News thread](https://news.ycombinator.com/item?id=50456631) on the repository had 405 points and 125 comments 2.7 hours after posting.

Both posts are AWS's own account, and neither gives a fidelity score or a defect rate. The claim that no person reviewed the code cannot be checked from outside. Goldberg calls his post the first in a series that will cover how the team measures fidelity and holds its security bar.

**Why it matters:** This is a vendor shipping a public codebase and saying in writing that the gate, not a person, decides what merges. The setup depends on two things most projects lack: a machine-readable spec for every operation, and a real system to test against. Goldberg names both as the reason he tried it. Teams weighing a no-review pipeline should ask first whether they have an equivalent of those two, and note what the product is: a test tool that AWS says not to use for production workloads or security testing.

## 2. Google prices a model call for routing and policy checks

**[Gemini Decisions API: Fast, calibrated multimodal decisions](https://blog.google/innovation-and-ai/technology/developers-tools/gemini-decisions-api/)** · Min Choi and Felix Yu, Google DeepMind · Google blog, November 11, 2026

Google released an endpoint that answers closed questions and returns no generated text. A request carries one input of up to 256K tokens and up to 1,000 independent questions. Each question is a yes/no check, a choice among 2 to 255 options, or a score on an ordered rubric, and each answer comes back with a confidence value from 0 to 1. Google quotes 150 to 250 ms end to end for contexts up to 16K tokens, and a price of $0.10 per million input tokens with no charge for output. The post lists tool selection, policy checks, model routing, and context grading as intended uses, and says Google Search uses the endpoint as a safety layer for MCP tools. Integrations are "rolling out" to OpenRouter, LangChain, LiteLLM, OpenCode and others.

Google says the model, Gemini Decision 1, leads its benchmark suite with the lowest calibration error and is "nearly 5x cheaper" than Gemini 3.5 Flash-Lite on the same suite. Those are Google's own measurements.

**Why it matters:** A harness makes many small decisions per task: which tool, which model tier, whether an action breaks a rule. A generative call for each one adds latency and cost. A cheap endpoint with a confidence value lets the code send low-confidence cases to a slower model or a person. The calibration claim is the one to test on your own traffic before a gate depends on it.
