Accountability Stays Human: Whoever Ships, Watches

Intercom auto-approves over 19% of pull requests with no human reviewer in the loop, and over 93% of PRs in its two main codebases are agent-driven. Neither number moved the accountability line one inch. Their rule, stated in the post that announced the system: "The engineer who ships a change is expected to watch it go live, monitor its behaviour in production, and be ready to roll back if something isn't right. AI approval doesn't change that. The human who ships the code remains accountable for the outcome."

You can automate authorship and you can automate approval, but the role that holds the consequences stays human, and it attaches to shipping, not reviewing.

Review was never the accountability mechanism

Intercom's sharpest observation cuts against the instinct to anchor accountability at the approval gate: "those product changes that did cause outages in the past? They were all reviewed and approved by humans." Human review, in their words, "is not a guarantee of safety. It never was."

The deeper reason is structural. "Only in production do you discover the unknown unknowns." Intercom reports that the majority of its largest outages were not caused by product code changes at all: they were infrastructure issues, unanticipated customer usage patterns, or third-party outages. No reviewer, human or AI, was ever going to catch those, so the accountable role has to sit where production behavior first becomes observable: with the person who ships. That is why the obligation is phrased as watching, monitoring, and rolling back, not as having approved carefully.

This is the companion rule to segregation of duties, and the two roles sit a step apart in the same workflow. Who may approve a change is a decision-gate question, covered in the author is never the approver. They are deliberately different roles held by different people.

Small batches make the obligation real

An accountability rule you cannot physically discharge is theater. Intercom's shipping system is built so that watching a change go live is a feasible act, not an aspiration:

• Average time from merge to running in production is 12 minutes, so the shipper is still at their desk, context intact, when the change lands.
• Small batches are enforced, not encouraged: the review agent "won't approve large PRs." Oversized changes get flagged and broken down (scope discipline as a control).
• Small changes are "easier to catch problems, and roll back when something goes wrong as the context is still fresh in your head."

The result they report: downtime from breaking code changes dropped 35% even as deployments doubled. Their framing is that speed is a prerequisite for safety, because "accumulating code creates risk." A human can credibly watch a one-screen diff deploy twelve minutes after merge. Nobody can credibly watch a week of accumulated changes deploy at once.

The human is on the hook, but not abandoned

Two design choices keep the rule from becoming "the engineer eats whatever the agent did."

First, opt-out is unconditional: "Any engineer can request a human review on any change, at any time. The system is a tool, not a mandate." The shipper who will carry the outcome can always demand more scrutiny before accepting it. See review as a gate.

Second, the data says the hook rarely gets pulled. In Intercom's controlled pilot of over 100 PRs, AI-approved changes had zero reverts. In the first four weeks of broader rollout, 497 PRs went fully autonomous, with Claude writing the code and the AI pipeline reviewing, approving, and shipping it.

Intercom is candid that they "don't expect that to hold at zero forever." The point is not perfection. It is that asking a human to stand behind AI-shipped code is a reasonable demand when the code reverts roughly 10x less often than the human-authored baseline.

Auditors accept the split, on evidence

Intercom's compliance section makes the same separation the architecture does: "The 'who' may change, but the 'what' doesn't." Every AI-approved PR is "labelled, logged, and queryable," with review comments, approval decision, test results, and merge event all recorded. They engaged their auditors, Schellman, before scaling, and confirmed the process meets SOC 2, HIPAA, ISO 27001, ISO 42001, and AIUC-1 requirements. An automated approver plus a named, accountable shipper satisfied the frameworks because the evidence trail and the responsible human both exist. The broader version of that argument is in the system carries responsibility.

Where the corpus is thin

Intercom is the only team in the three reports that has published this rule explicitly. The field is silent on three things worth pinning down before you adopt the rule: what "watching" means operationally (a time window, a dashboard, an on-call handoff), what happens when the human who initiated a task and the human who ships it are different people, and whether the rule survives autonomy levels where merges happen outside working hours. Until someone publishes, treat those as working agreements your team writes for itself, not settled practice.