Auto-approval by risk: the human leaves, the gate stays

Exactly one production system has first-party, auditor-confirmed evidence for agent-written code shipping without a human reviewer: Intercom auto-approves 19% of PRs, but only inside an enforced multi-agent review pipeline that refuses large changes and logs every decision. A second case, Coinbase, has a thinner public record that points to auto-merge for narrow low-risk classes only: copy changes and minor bug fixes, per the best available secondary sourcing. This is the deepest a decision gate goes before it disappears entirely, and in the published record it never fully does: "no human in the loop" means risk classification decides which gate applies, not that the gate is gone.

Intercom removes the human, not the review

Over 93% of PRs in Intercom's two main codebases are agent-driven, and over 19% are auto-approved with no human reviewer. The pilot was over 100 PRs through the approval pipeline: zero reverts, and a 6–16x improvement in time-to-approval at the 75th percentile. In the first four weeks of broader rollout, 497 PRs went fully autonomous: Claude wrote the code, the AI pipeline reviewed, approved, and shipped it.

The approval is automated; the pipeline around it is mandatory. Review is decomposed into independent sub-agents (problem-description quality, intent alignment, safety, logical correctness, best practices), and the reviewer traces execution paths through the codebase rather than reading the diff alone. The agent won't approve large PRs: too big or too broad gets flagged and broken down, which is scope discipline working as a control (see Scope Discipline). Any engineer can request a human review on any change, at any time. And the engineer who ships remains accountable for watching it go live and rolling back, which is the model Accountability Stays Human builds on.

The production data backs the design. AI-authored backend code reverted at 0.53% versus 5.39% for human-authored; frontend, 0.22% versus 2.00%. Every AI-approved PR is "labelled, logged, and queryable," and Intercom engaged its auditors, Schellman, before scaling, confirming the process against SOC 2, HIPAA, ISO 27001, ISO 42001, and AIUC-1.

Coinbase is the thinner auto-merge case

Coinbase's PR review cycle time was roughly 150 hours, most of it queue; Chintan Turakhia says on the "How I AI" podcast they cut it 10x to roughly 15 hours. The mechanism is not first-party documented. Per Kishan Dahya's account citing Turakhia, it is auto-merge by risk: low-risk changes (copy, minor bug fixes) merge automatically; higher-risk changes go through review.

Every first-party Coinbase source keeps a human on the merge button. The Linear case study describes Forge drafting a PR and pushing it back to Slack "for review." Coinbase's own Mux engineering post says "the engineer reviews each as it finishes, provides feedback, and merges." CEO Brian Armstrong, targeting >50% AI-generated code: "Obviously it needs to be reviewed and understood." Removing human review from the critical path entirely is described in Dahya's account as where Coinbase is going (15 hours toward 5 minutes), not where it is.

The "agent councils" claim rests on one unverifiable tweet

LangChain's Open SWE comparison table summarizes Coinbase's validation as "agent councils + auto-merge." The corpus does not support that phrasing at face value. The term "agent councils" traces to exactly one source: Dahya's article, which cites a Turakhia tweet that is not publicly recoverable and a podcast whose full transcript contains zero occurrences of "council," "auto-merge," "Greptile," or the relayed "95%+ better than human" quote. No Coinbase blog post, repo, or talk uses the term, including the Mux post published a month after Dahya's article. The link LangChain attaches is a miscitation pointing at a different Coinbase system entirely. Even in Dahya's telling, councils do first-pass code review, a pre-filter feeding the risk classifier, not a merge authority. Treat the defensible version as: Coinbase auto-merges a narrow low-risk class and publicly aspires to go further.

What removing the human actually requires

Strip both systems to their mechanism and the pattern is the same: classify the change, and remove the human only where an automated gate plus a small blast radius covers the risk.

The defensible pattern is not model confidence alone. The auto-approval sits downstream of an enforced pipeline (Review as a Gate) and a reviewer architecture (AI Reviewing AI). Nobody else has published auto-approval mechanics at all: if you are building one, Intercom's version is the only fully documented, audit-confirmed reference, and "low-risk classes first" is the only expansion path the public record supports.

The third shape: an AI approver races the human on the same gate

The structurally different design keeps the human gate on every change and gives the same gate instance two live resolvers. The gate carries a standing offer to an AI approver. Eligibility is an event condition that puts the AI on the gate, written in the same matched-filter grammar event routing uses for triggers rather than as a pre-assigned risk tier. Criteria are the written standard the AI must satisfy to approve. When an eligible event arrives, the system spawns a real review turn: the AI checks out the actual change in a working environment and evaluates it against the criteria, rather than judging from the event payload.

First write wins. The human's click and the AI's verdict race on a conditional update; exactly one settles the gate, and the other is a no-op. An aborted turn or an unclear verdict settles nothing, so the gate stays open for a person. A rejection routes through the same failure path a human rejection takes, feeding the loop back to the author (the workflow state machine covers how a gate step settles).

Intercom and Coinbase decide up front which changes skip the human, so once a change clears the classifier, no human decides that instance. When the AI wins the race, it removes the wait, not the reviewer.

The cost runs the other way: no class is guaranteed to skip the queue, so the human attention the gate consumes depends on the AI's latency and approval rate rather than on a class boundary. And no production team has published this shape. It falls out of building approval as a step in a workflow engine, where a gate is a standing decision point any authorized resolver can settle, rather than a branch in a merge policy.