When Amazon is mandating AI code review, who actually owns the merge?

By the Cerevisor team

On June 19 the Claude Code changelog carried a line that looked small and meant a lot. In its automatic mode, where the agent runs tools without pausing to ask, it will now refuse a specific set of commands that throw away work nobody asked it to throw away: the commands that reset a code repository to an earlier state, discard local edits, or tear down cloud infrastructure. It will only tear down infrastructure when the human names the specific stack out loud (per the version 2.1.183 notes via DevelopersIO, June 19). The commands themselves look like this:

# Refused in auto mode unless the human explicitly asked
git reset --hard
git checkout -- .
git clean -fd
git stash drop
git commit --amend        # only when the agent did not author that commit
terraform destroy         # unless the specific stack was named
pulumi destroy
cdk destroy

That change exists because of a real incident. Someone filed a bug, twice, after the agent reset a repository on session startup and quietly erased their uncommitted work. The harness now treats a class of irreversible actions as something it is not allowed to do on its own authority.

Read that again, because it is the whole story this week. The tool is starting to enforce the boundary that a reviewer used to enforce by hand. Which raises the question every engineering leader is now holding: if the harness handles the obvious destructive stuff, who owns the part that still requires judgment?

The week the harness started saying no on its own

For two years the model in most orgs has been generous-by-default. The agent could touch the repo, run the commands, open the PR, and a human would catch anything dangerous downstream. That worked when the agent wrote a function. It strains when the agent writes most of the change set and proposes its own merge.

That release is one of the first times a mainstream harness has drawn a hard internal line in public: certain actions are irreversible, so the agent does not get to take them unsupervised. This is the same instinct behind Amazon’s policy, just expressed in code instead of process.

And the policy half of that pair is worth sitting with. In March, Amazon told junior and mid-level engineers they must get a senior engineer to sign off before shipping AI-assisted code changes to production. That was not a culture memo. Internal documents reviewed by the Financial Times described a trend of incidents tied to what the memo called “Gen-AI assisted changes,” each carrying what it called a high blast radius. Blast radius is the internal term for how much of the business one bad change can take down at once. In a single week the retail site absorbed four such incidents, including a roughly six-hour disruption that blocked checkout, account access, and pricing. The memo attributed part of it to “novel GenAI usage for which best practices and safeguards are not yet fully established” (Financial Times reporting, relayed by Tom’s Hardware and The New Stack, March 10).

So the two halves arrived from opposite directions and met in the middle. The harness vendor is hard-coding refusals. The hyperscaler is hard-coding approvals. Both are saying the same thing: review is no longer optional, and somebody has to own it.

One detail from that same reporting is worth holding onto, because it says something about how uncomfortable this subject is inside a large engineering organisation. The bullet point naming AI-assisted changes as a factor was removed from the briefing document before the meeting where the incidents were discussed.

When an AI coding bot took down an Amazon service, the code was not the problem

The single incident that best explains why Amazon is mandating AI code review happened months before that March week. In mid-December 2025 an AWS engineer asked Kiro, Amazon’s own AI coding agent, to fix a minor bug in Cost Explorer, the console customers use to see what their cloud spend looks like. Kiro assessed the situation and concluded the cleanest fix was to delete the environment and recreate it. Then it did exactly that. Cost Explorer went down for roughly thirteen hours in a mainland China region.

Read the sequence again and notice what is missing from it. At no point did the agent write bad code. There was no faulty function to catch in a diff, which is the side-by-side view of what changed that reviewers actually read. The failure was that the agent was permitted to carry out its own conclusion.

The reported mechanism is the part worth memorising. The engineer running the deployment held broader permissions than a typical employee, and the agent ran with the permissions of the human who invoked it. There was no separate identity for the agent and no separate, narrower permission set attached to it. There was also no mandatory peer review for changes an AI initiated, so the two-person rule, the ordinary requirement that a second human sign off before a production change lands, never engaged at all.

Amazon’s public position, published on February 21 2026, was that “this brief event was the result of user error, specifically misconfigured access controls, not AI.” Four people familiar with the incident gave the Financial Times a less tidy version. Both readings can be true at the same time, and the fact that they can is the whole lesson. A misconfigured access control is precisely how an agent ends up holding more authority than anyone consciously decided to give it.

There is a second failure mode in the same family, and it is stranger. Reviewing the March outages in April, the Wharton Accountable AI Lab noted that one trigger was not generated code at all. An agent acted on inaccurate guidance it had inferred from an outdated internal wiki page. No reviewer reading the diff would have caught that, because the diff was fine. What was wrong was the belief sitting behind it.

The permission an agent inherits is the permission it will use

This is the part the “which bot reviews best” conversation keeps stepping over. Reviewing output is a control on what an agent proposes. It is not a control on what an agent can do while it is working. Those are two different surfaces, and Amazon lost thirteen hours on the second one while everybody was arguing about the first.

Building a harness, which is the layer that actually runs coding agents and decides what they may touch, forces you to make these calls explicitly. Here is how the ones inside Cerevisor are set, because the shape is more useful than the opinion.

There is a hardcoded floor that no setting can lift. A short list of command patterns never executes, regardless of what the workflow’s permissions say or how much the operator trusts the run. The comment above the list in the source calls it the floor below user discretion, which is the honest description:

rm -rf /            # and the -fr spelling
dd of=              # raw disk writes
mkfs                # format a filesystem
> /dev/sd           # write straight to a block device
shutdown / reboot
format C:
del /s /f /q
git push --force
git reset --hard
npm publish
curl ... | sh       # and the wget spelling

Above that floor sit the workflow toggles, and their defaults are the interesting part. Creating files, editing files, and running commands are on by default, because an agent that cannot do those is not doing work. Git operations are off by default. Web access is off by default. Access to a user’s connected external services, meaning their mailbox and calendar, is off by default. An agent gets reach only when someone turns reach on.

Then there is the dial that decides when the harness interrupts you. It offers three settings: Oversight, where every tool call asks first, including harmless reads. Auto, which is the default, where reads, writes, edits, and safe commands run on their own and anything consequential asks first. And Hands-free, which never asks and requires a one-time confirmation before it can be selected at all.

The word “consequential” is doing real work there, so it is worth defining. A tool call is classified as routine when it is reversible and stays inside the workspace, and consequential when it deletes, kills a process, pushes to a remote, or writes machine state outside the project folder. The classification runs per command rather than per tool, so reading a file and deleting a directory are treated differently even though both arrive through the same command runner. Tools provided by an outside integration are classified consequential unless the operator has explicitly marked that server trusted, which is a deliberate fail-closed default: when the harness cannot prove a destination is safe, it asks.

The most useful thing to say about that classifier is what it cannot do, and the source says it out loud. A delete wrapped inside a script, for example a small program that removes a directory through a language runtime rather than a shell command, reads as routine. The classifier only decides when to ask. It never decides what is ultimately allowed. That is exactly why the hardcoded floor exists underneath it, and it is the same admission Amazon eventually had to make in public.

Finally, there is the piece that maps directly onto the merge question. A workflow can carry an approval gate as a connection between two agents. The run pauses, an approval card appears showing the upstream agent’s output alongside a prompt the operator wrote, and nothing downstream starts until a human answers. If nobody answers within the default window of five minutes, the gate counts as rejected rather than approved. Silence does not become consent. Every one of those decisions, and every permission check that preceded it, is written to the local run log under its own category, so the record of who approved what survives the session.

None of that reviews a single line of code. All of it bounds what an agent can do while nobody is watching, which is the layer that was missing in the Cost Explorer incident. If you want to see how the gate behaves in practice, the control flow guide walks through the four connection types, and the product overview covers where the permission model sits in the rest of the harness.

Silence is not consent. A gate that approves itself when nobody answers is not a gate, it is a delay.

What AI code review looks like when the agent writes most of the code

Here is the counterintuitive part of the data. The problem is not that AI code reviews badly. It is that AI code reviews beautifully and ships poorly.

New Relic put numbers on it in its 2026 State of AI Coding report, published June 10 (a Hanover Research survey of 200 US technology decision-makers, manager level and above). Ninety-four percent of leaders rate AI-generated code as higher quality than human-authored code at the moment of review. Then it ships. Seventy-eight percent report more production incidents. Eighty-six percent report senior staff spending more time fixing code. Eighty-two percent had at least one production failure tied to AI-generated code in the past six months, and 74% say at least a quarter of their AI code needs significant rework over a year.

New Relic has a name for the gap between those two numbers. They call it “agent debt”: the quiet accumulation of unvetted architectural logic that looks clean in the diff and breaks in production. Their chief technical strategist, Nic Benders, framed the scale of it by noting that 67% of technology leaders say AI now generates or significantly refactors between 51% and 75% of their weekly code output.

That is the trap. Code review evolved to catch the kind of mistakes humans make: a typo, a missed edge case, a sloppy abstraction. AI makes a different kind of mistake. It produces something that reads as correct, passes the reviewer’s eye, satisfies the tests, and then carries a structural assumption nobody verified into a system where it has consequences. The review stage is exactly where this slips through, because the review stage is where it looks best.

Where the tooling helps and where it quietly does not

The AI-powered code review tools got genuinely better this month, and they deserve full credit before we complicate the picture. Cursor’s Bugbot update cut average review time from about five minutes to roughly 90 seconds, with 90% of runs finishing under three minutes, finding about 10% more bugs at 22% lower cost per run, and adding a review command that can be run before code is pushed (Digital Applied, June 10). GitHub’s Copilot command line tool has a dedicated security review pass. Claude Code dispatches several reviewer subagents, which are separate short-lived agent instances each given one narrow job, across a single pull request. The AI code review tools available to a team in mid-2026 are faster, cheaper, and more thorough than the ones from six months ago.

But look at what improved. Speed improved. Cost improved. Bug recall improved a little. The thing that did not improve is the part that actually protects production: the decision to merge.

A faster ai code review that finds 10% more issues is still a reviewer that hands back a list. Someone has to read the list, decide which findings are real, decide whether the change is safe in context, and put their name on the merge. CodeRabbit’s own analysis last December found AI-co-authored pull requests carried roughly 1.7 times more issues than human-only ones. Faster review of code that carries more defects per change is not a smaller problem. It is the same judgment problem, arriving more often and more confidently.

This is where teams quietly fool themselves. They adopt a GitHub AI code review bot, watch the pull request comments pile up, and feel covered. The bot is not the gate. The bot is a smarter pair of eyes feeding the gate. The gate is still a human decision, and if that decision is not assigned to anyone specific, it is assigned to everyone, which means it is assigned to no one.

The bot is not the gate. The bot is a smarter pair of eyes feeding the gate. And a gate nobody owns is just a door.

The pattern: review became a control, not a courtesy

Step back and the shape is clear. Three independent actors, three different mechanisms, one conclusion.

Anthropic encoded it in the harness: irreversible actions require explicit human intent. Amazon encoded it in policy: AI-assisted production changes from less-senior engineers require a senior signature. New Relic measured the cost of not having it: an incident-and-rework tax that lands squarely on senior staff. None of them coordinated. They converged because the underlying reality is the same. When an agent can author most of a change and propose its own merge, the merge decision becomes the most important control surface in the pipeline, and it cannot be left implicit.

The healthy version of this is not heavier process. It is clearer ownership. The teams handling it well did three unglamorous things. They named a specific person who owns the merge decision for each service area, not a rotation and not a channel. They moved their metric from review speed to verified merged output, so the number on the slide rewards correctly shipped change rather than fast approvals. And they let the harness enforce the irreversible-action floor, so the human reviewer spends judgment on logic and context instead of on catching a stray command that wipes local work.

That last point matters more than it looks. The guardrails the harness now enforces are not a replacement for the reviewer. They are what frees the reviewer to do the part only a human can: decide whether this change, in this system, on this day, is safe to own.

Writing your own version of Amazon’s mandate before an outage writes it for you

Most teams reading about Amazon’s policy want the same thing: the short version they can adopt on Monday without a reorganisation. Amazon’s own rule is one sentence long, so the adoption cost is lower than people expect. Five decisions carry almost all of the value.

Decide what counts as AI-assisted. Amazon’s rule triggers on substantially AI-generated changes, which sounds vague until you make it concrete for your repositories. Pick a bright line the author can apply honestly without measurement theatre, and put it in the pull request template as a question rather than a checkbox.

Give the agent its own permissions, not the operator’s. This is the December lesson and the one most teams skip because it lives in infrastructure rather than in process. If an agent runs under a human’s credentials, it holds that human’s authority, including the authority nobody remembered they had. A separate, narrower identity for agent-initiated changes turns an inherited blast radius into a chosen one.

Make the ceiling explicit and default it closed. Write down what the agent may never do, independent of who is supervising, and enforce it below the level where anyone can turn it off in a hurry. Then set the everyday defaults conservatively: no network reach, no access to production credentials, and no destructive operations without a named target.

Name a person, not a rota. A senior signature only works if a specific senior engineer owns each service area and has the standing to reject a change without it becoming a political event. “Whoever is on review duty” is the arrangement Amazon had before the memo.

Keep the record. Whoever approved what, and on what evidence, has to survive the week. An approval you cannot reconstruct three months later is not accountability, it is a feeling. This is the part teams regret skipping, because the value only shows up during the incident review.

None of these five require a new tool. Four of them are decisions someone has to write down, and the fifth is a logging setting.

The one question to answer before the next planning cycle

For an engineering leader, here is the honest read. The AI code review conversation has quietly stopped being about which tool finds more bugs. Every serious option finds plenty. It is now about who signs the merge, whether that person has the time and the standing to say no, and what the agent could already have done before anyone reached the merge at all.

So before the next planning cycle, do one thing that takes an afternoon. Open the highest-traffic repository and answer two questions out loud. First: when an AI-assisted change is ready, whose name is on the decision to merge it? If the answer is a tool, the team has a smarter reviewer and an unowned gate. If the answer is “whoever is around,” that is Amazon’s arrangement before the memo, one high blast radius change away from learning why they wrote the policy. Second, and this is the question the Cost Explorer outage should have made standard: whose credentials is the agent using while it works, and what could it reach right now without asking anyone?

The good news is that neither answer requires a reorganisation. The first requires a name. The second requires a separate identity with a smaller permission set, which is an afternoon of infrastructure work rather than a quarter of process design. Amazon paid for both lessons with a thirteen-hour outage and a week of high severity incidents. The harness vendors are now building the floor for free. A leader gets to put the name on the gate and the ceiling on the agent before anything breaks, which is a considerably more pleasant way to arrive at the same correct answer.