Intercom: The Only Published Case of Merging Without a Human Reviewer

Intercom pushes code to production hundreds of times a day, and the average time from merge to production is 12 minutes (Intercom, self-reported, observed 2026-10-28). Then coding agents took over the writing. More than 93% of the pull requests in its two main codebases became agent-driven, and a working change could arrive in minutes (Intercom, self-reported, observed 2026-10-28). The approval step did not get faster. The authors describe the two ways that ends. The queue backs up and the whole line slows to the pace of its reviewers, or the reviewers start glancing at a diff, skimming the description and clicking approve, so the check keeps its name and loses its meaning. Either way you pay every day: in waiting you can see, or in unread code you cannot see until it breaks. Intercom's answer was to let a review agent approve some changes with no human reading them, and to make that agent strict enough to deserve it. Decide now: which kinds of change would you let merge with no human reader, and what must the reviewer be allowed to do to every change it cannot judge?

This lesson gives you factory/adopt/intercom.md - an eligibility rule for no-human approval with size limits, tripwires and a sample audit. It serves the Prove stage of the course loop (Slice, Gate, Run, Wrap, Prove): Intercom's case is evidence you weigh before you let any lane go unread, and the file is the charter entry that records what you accept and what you will measure.

What is actually going on

Intercom publishes one stage of its line in detail: what happens between an agent opening a pull request and that request merging. What starts the agent and where it runs are not in the post. What is there is a review agent that refuses to treat review as one task. It splits the work into sub-agents with one job each: judge the quality of the problem statement in the description, check that the diff matches the stated intent, look for safety problems, check the logic, and compare the code with best practices and known anti-patterns (Intercom, self-reported, observed 2026-10-28). It also traces execution paths instead of reading only the changed lines, using guidance its engineers wrote about their own code.

Two human loops sit around it. Engineers mark the agent's comments helpful or not, and those marks refine the guidance, so the reviewer improves with use. And any engineer may request a human review of any change at any time, so the agent's approval is a default, not a mandate.

The size gate is what makes the design safe. The agent will not approve a change that is too big, too complex or too broad. It flags the change and requires a split. The authors argue that this gives engineers a direct reason to ship small, well-scoped changes, which are easier to review, to test and to roll back. Read that as a designer: the reviewer's most important output is a refusal.

Qualifying changes merge with no human in the loop. Shipping does not end at merge, though. The engineer who shipped is expected to watch the change go live, watch how it behaves and be ready to roll back, and AI approval leaves that duty where it was. Every AI approval is labelled, logged and queryable: the comments, the decision, the test results and the merge event are recorded, so an auditor sees the same evidence whether a person or an agent approved.

"Only" in the title is narrow: Intercom is the one source here that publishes a live share of no-human merges next to outcome figures. Anthropic also describes a low tier that needs no person once checks pass (Anthropic Claude Code team, self-reported, observed 2026-10-28), and GitHub offers an opt-in approving reviewer (GitHub changelog, observed 2026-10-28).

The diagram follows one pull request: refusal loops back to the author, approval ends in a person who owns the rollback.

One branch is drawn as unknown on purpose: the post does not say what happens to a change the agent declines for a reason other than size, beyond the fact that a human review is always available.

The rule and its condition

Use agent approval with no human reader only for changes that pass written size limits and eligibility tests, and only while the revert tripwire is quiet; otherwise a person reads the change. The condition you can check on any day is whether the reviewer is able to refuse. If it cannot reject an oversized change, you are not running Intercom's design. You are running a stamp.

The table gives Intercom's line in the seven dimensions this module uses for every company. Each cell with a number carries its source in the last column.

What it does well. It turns the cost problem into a size rule: the reviewer will not approve a big diff, so the cheapest path for an author is a small, easy-to-roll-back one. It starts with a pilot, using reverts as the exam. It records every AI approval to an auditor's standard, with the auditor brought in before scaling. And it states its own limit: revert rates will not stay at zero, and most of its largest outages came from infrastructure, usage patterns or third parties, which review cannot catch.

What it costs. A reviewer you must keep calibrated, which is standing engineering work. Some incidental learning, since nobody absorbs code by reading a change no person reads. And claims you cannot verify: every figure is the company's own, and the eligibility rule that would let you reproduce the lane is missing.

Worked case

Six mechanics come out of the post. Each ties to a lesson of this course.

1. The refusal is the control. A diff small enough to judge is what permits a machine to approve it. This is the size-refusal clause of Lesson 07, and it is why the size limit belongs in your file as a number, not an intention.

2. A no-human lane must be set by a rule. Lesson 04 says a bot approval never fills a required human slot. Intercom's design can be consistent with that only if the lane is chosen by a rule and the reviewer's verdict is one input to it. The post does not say who owns the rule, so your file names an owner and bars the author, human or agent, from overriding it.

3. Pilot, then ramp, with reverts as the exam. More than 100 pull requests went through first with zero reverts, and only then did 497 go fully autonomous in four weeks (Intercom, self-reported, observed 2026-10-28). That is autonomy set per lane (Lesson 03) after a readiness check (Lesson 09). Your pilot needs its exam written before it starts.

4. The shipper owns the rollback. Merge-to-production is short and the author stays on duty (Lesson 10). Small changes and a fast rollback path are what make a mistaken approval cheap.

5. Audit parity. A label, a log and a query make an agent approval as inspectable as a human one, and Lesson 12 on tracing every commit to a human says who the trail must end at.

6. Outcome numbers need guardrails. Pair the revert comparison with downtime, volume and a baseline, because a rate with no denominator is the failure Lesson 14 warns about.

Two independent studies pull in different directions, and both are about open-source projects, not enterprises. A preprint of 400 reviewers and 11,429 reviews found approval of agent pull requests rising from 30.1% to 36.8% within the same reviewers while their inline comments fell (preprint, peer review not confirmed, observed 2026-10-28). That supports Intercom's premise that human approval decays with exposure, but the authors cannot separate habituation from earned trust. A second study, accepted at MSR 2026, found that pull requests reviewed only by a code-review agent merged at 45.20% against 68.37% for human-only review (MSR 2026 study, observational, observed 2026-10-28). That is a caution. An agent reviewer that only comments is not the same as one with a size gate and a pilot, but the study shows why you measure the reviewer's signal and not just its presence. The coined rule for this lesson: Let the reviewer refuse before you let it approve.

Illustrative composite. A 9-engineer logistics app. Agents open about 40 pull requests a week. Last month the largest agent pull request changed 61 files. Human-authored changes on the same paths revert about 4% of the time. All figures are modeled, not measured.

Three designs are on the table. Design A: set a goal that one in five agent pull requests merge with no human reader, and tune the reviewer until it hits it. Design B: let any change merge unread when checks are green and the AI review is clean. Design C: write an eligibility rule with size limits, tripwires and a sample audit, and pilot it before the first unread merge. Decide now: which design, and what is the first thing that breaks in each one you reject?

Design A breaks first, and by construction. A share is an output, so the reviewer learns to approve to hit the number. Intercom's authors raise this exact worry, a goal that makes you optimise the metric over the outcome, and answer that the reviewer is strict and refuses big changes; the target alone is not the safeguard. Design B breaks on the first change the checks cannot see, and the composite's largest agent pull request shows how it gets there: no size limit means a large agent change sails through on green. Design C is the build. Its numbers are starting values from this course, not Intercom's, because Intercom has not published its own.

Here is the file, in full. Fill each <...> cell for your repo, or accept the starting value by writing it into the last column.

The validator checks that no cell is empty or still a placeholder and that every section survives. Run it from your repo root. Avoid angle brackets in your own values, since the check treats them as placeholders.

awk -F'|' '/^\|/ && !/^\|[-| ]+\|$/ { for (i = 2; i < NF; i++) { c = $i; gsub(/^ +| +$/, "", c); if (c == "" || c ~ /<[^>]*>/) { print FILENAME ":" NR ": " $0; bad = 1; break } } } END { exit bad }' factory/adopt/intercom.md && for h in "## Size limits" "## Eligibility tests" "## Never eligible" "## Tripwires" "## Pilot gate" "## Sample audit" "## Audit record"; do grep -q "^$h" factory/adopt/intercom.md || { echo "missing heading: $h"; exit 1; }; done && echo OK

Tested on a scratch copy of the template: the unfilled template failed and listed the offending rows, the same file with every placeholder replaced passed with OK, one emptied cell failed and named its line, and a renamed section failed with missing heading.

Faded case

Skip to the open case if this is familiar. The table sets Intercom beside three other published designs, using only facts from their sources.

Sources, all observed 2026-10-28: Intercom (self-reported); Anthropic (Claude Code team, self-reported, security post, code review product page); Stripe (self-reported); GitHub (approving-reviewer changelog and cloud agent guardrails).

Read down the first row. Stripe keeps a human on every merge, so its safety comes from deterministic steps and a person. Anthropic opens a no-human tier only for the lowest-risk changes, classifies by the change, and has humans sample automated approvals; its engineers also want circuit breakers that tighten approval when revert or incident rates move, before more zero-human merges (Anthropic Claude Code team, self-reported, observed 2026-10-28). GitHub's rules are the most conservative. Intercom alone publishes both a live no-human share and outcome claims, so it is the case to study and the one to doubt hardest.

Your decision. Your organisation requires one human approval on every merge, as Stripe's does, and will not change that this year. Which two Intercom mechanics do you still copy, and which one do you leave out?

Open case

This section is the course's judgment, not Intercom's advice.

Solo developer. Copy the size limit and a next-day self-audit of what the agent shipped. Skip the large shadow-pilot count; you will not generate the volume. First week: write the size limits and run the reviewer in shadow on every change.

Small team. Copy the whole file, with the audit sample at its starting value. Skip any share target. First week: measure your human revert rate on the paths you would open, then start the shadow pilot.

Enterprise. Copy the audit record and the early auditor conversation. Skip a company-wide switch. First week: choose one codebase and one path group, and assign an auditor who is not the owner.

Regulated shop. Copy the label, log and query for every approval. Skip the no-human lane until your auditor accepts the evidence in writing. First week: send the audit record table to your auditor.

A director has read the Intercom post and sets your team a target: one in five agent pull requests merging with no human reader by the end of the quarter. Your reviewer posts comments and has never refused a pull request. You have no revert counts split by author type. Say what you do first.

Where this breaks

Everything above rests on one company's account of its own data. The figures are self-reported, the revert comparison is not controlled for pull request size or type, and the post gives no volumes behind the percentages, no revert count after the pilot and no catch rate for the reviewer. A reviewer that never misses would show the same zero reverts as one that is lucky for a month. No outside group has replicated any of it, and the reviewer's model was not confirmed from the page.

The part you most need is the part not published: the eligibility rule. Which change classes qualify, and where the size cap sits, decide whether this is safe or reckless, and the build above fills that gap with this course's starting values, not Intercom's. Treat them as hypotheses to test in your shadow pilot.

The third limit is structural. Pull request review, human or agent, does not see most of what takes a service down. Intercom's authors say the majority of their largest outages came from infrastructure, unexpected customer usage or third-party failures. A no-human lane makes review cheaper; it does not make production safer by itself. What would change the verdict: a published eligibility rule, absolute counts, and a revert rate for no-human merges compared with human merges on matched paths and sizes.

Key Takeaways

• Refuse oversized changes first; a diff too big to judge is never eligible for unread approval.
• Write the eligibility rule yourself, because Intercom has not published which changes qualify.
• Run a shadow pilot with a pre-agreed revert exam before the first unread merge.
• Sample unread approvals every week and trip the path group back to humans on a revert.
• Read self-reported revert gaps as a direction, never as proof of safety.
• Let the reviewer refuse before you let it approve.

What You Have Now

factory/adopt/intercom.md - an eligibility rule for no-human approval with size limits, tripwires and a sample audit. It is a header table, size limits, eligibility tests, a never-eligible list, tripwires with a response, a pilot gate, a sample audit and an audit record, plus a validator that fails on any empty cell. This is the Prove stage entry for one risky choice: it says what you would let merge unread, what pauses it and how you will know. Keep it beside your risk lanes from Lesson 07 and feed its tripwire numbers into the scoreboard from Lesson 14.

Further Reading

• Intercom, "AI is approving our pull requests: here's how we made it safe": the primary account, including the pilot, the revert figures and the audit design.
• Anthropic, how it secures its AI-native development lifecycle: risk-tiered approval, shadow mode and human sampling of automated approvals, from the party that cites Intercom.
• Anthropic Claude Code team, "Solving code review at Anthropic": the round cap, the risk-tier classifier and the engineers' own call for circuit breakers.
• Habituation at the Gate (preprint): independent evidence that human approval of agent pull requests rises while inspection falls.
• GitHub changelog: Copilot code review can now approve pull requests: the platform view, an opt-in approver that is off by default.

Exercises

1. Measure your baseline. For the path group you would open first, count merged changes and reverts over a recent period you can still audit, and write the human-authored revert rate into the header table.
2. Fill the template for one repo. Copy the block to factory/adopt/intercom.md, replace every placeholder, run the validator until it prints OK, and write a sentence saying why each never-eligible path is there.
3. Plant a bad change. Make one deliberately wrong pull request that is under your size limit and one that is over it. Run both through your reviewer in shadow mode and record which was refused and which was caught. Decide what the result says about your limits.

Check your understanding