The On-Call Rotation We Had to Redesign for an Agent-Assisted Codebase

Three months ago we paged an engineer at 2 a.m. for a bug in a module she had, technically, authored. Her name was on the commit, her review approval was on the PR. She had no memory of the specific logic that broke, because she had reviewed an agent's implementation of a well-scoped feature, approved a clean diff, and moved on to the next ticket weeks earlier. This isn't a criticism of her: the review was thorough, the tests passed, the feature worked for three months before it didn't. The old on-call assumption, that the author remembers why the code does what it does, quietly stopped holding, and it took that specific page for us to notice.

Why the old assumption held for so long

Incident response has always leaned on tribal memory. You page the person closest to the code, and closest used to mean "wrote it, therefore understands it at a level no amount of reading the diff replicates." That proximity was reliable for years because writing code and understanding it were nearly the same act. Reviewing an agent's diff and approving it is a lighter cognitive commitment than writing it, even when the review is careful: you can correctly verify that a piece of logic does what it claims without building the same durable mental model you'd get from typing it yourself, line by line. Our rotation still assumed "on the commit" meant "carries deep context." For a growing share of our codebase, that stopped being true well before we noticed.

What changed after that page

The centrepiece of the fix is a plan artefact, not a diff. When an engineer has the agent draft a plan before writing code, the practice we described in our piece on reviewing agent-drafted PRs, that plan now stays linked to the PR permanently instead of living only in a chat thread that gets lost. During an incident it's often a better first read than the diff itself, because it states the intent and the assumptions in plain language instead of requiring someone to reverse-engineer intent from implementation at 2 a.m.

We paired that with two smaller changes. Every PR now records who scoped the task and reviewed the agent's plan, separately from who clicked approve on the final diff, because those are often different people: someone scopes a piece of work in the morning and hands the ticket to a colleague who's free to review the agent's output that afternoon. And we turned off the incident tooling's habit of auto-suggesting an escalation target from git blame for anything touched in the last six months. A clean blame entry no longer means a reachable expert exists, so we page whoever is on the rotation and hand them the plan artefact and the original ticket alongside the diff, rather than hunting for one specific person who might remember.

What this actually buys, using her page as the test

Run that same incident through the current process and it goes differently, not because anyone remembers more, but because nobody has to. The engineer on call that night wouldn't need to track down the original reviewer at all. She'd pull the plan artefact linked to the PR, see the stated assumption about how the feature was meant to behave, and check that assumption against what actually broke, which is a five-minute read instead of an hour spent reconstructing intent from code alone. We haven't recovered the old proximity model, and we don't think it can be recovered. What we have instead is a rotation that no longer depends on any one person's memory surviving the months between writing a plan and needing it again.

---

If your incident response process still assumes the commit author is the person who understands the code, it's worth an audit before that assumption fails during a real page. This is work we do inside our tech consultancy engagements. Talk to us.