The Pager, Not the Reviewer, Decides Who Owns Agent-Written Code

Code review used to double as an ownership check. The person who wrote the change understood it, a second person read it, and between them two people could debug it at 3am. Agents broke that link. An approved pull request now proves that someone read a diff. It proves nothing about whether anyone on the rotation can explain how that code fails.

My position: for any code path that can page a human, the merge test should be "the person who'd get paged can explain how this breaks without asking the agent." Not "a reviewer approved it." Whoever can pass that test owns the code. If nobody can, nobody owns it, whatever CODEOWNERS says.

Why this is coming up now

On October 29, The Pragmatic Engineer published a long look at AI SRE tools (opens in a new tab), the category of agents that triage pages, correlate signals and propose root causes before a human is woken up. The pitch is easy to like. Agents are shipping more code, there are more alerts, so put agents on the alerts too.

That pitch skips a question. When the AI SRE agent says "the root cause is the retry change merged on Tuesday," someone has to decide whether to believe it. That person needs to understand the retry change. If an agent wrote it, a different engineer approved it in four minutes, and the on-call engineer has never opened the file, then the system has two agents and zero people who understand the code.

The evidence that understanding is the thing slipping

Three findings from this year point the same way.

The code isn't getting worse. Anthropic's October 2026 workforce report (opens in a new tab) found commits per engineer at roughly 5x their level six months earlier, and "no difference in rates of lines of code subsequently removed or reverted" between agent-written and human-written code. If you're arguing that agent code is sloppy, the data isn't on your side.

Understanding of the code is getting thinner. In Anthropic's randomized trial on AI assistance and coding skills (opens in a new tab), published in January, 52 developers learned a new Python library. Those with an AI assistant averaged 50% on a follow-up quiz, against 67% for those who coded by hand, and finished only about two minutes faster. The authors noted that "the largest gap in scores between the two groups was on debugging questions." Debugging is the one skill on-call depends on.

Stability is where AI adoption still hurts. Google's 2025 DORA report (opens in a new tab) found AI adoption now goes with higher throughput, but still has a negative relationship with software delivery stability.

Put those together and you get a specific risk. The code is fine on average, there's much more of it, and the people responsible for it understand less of it each month. That doesn't show up in review metrics or revert rates. It shows up in how long the first bad incident takes to resolve.

The incident that wasn't about bad code

Amazon's March retail outages are a useful example because of what didn't happen. After the Financial Times tied the outages to AI, Amazon said that "none of the incidents involved AI-written code," and that the one AI-related incident came from "an engineer following inaccurate advice that an agent inferred from an outdated internal wiki," as Fortune reported (opens in a new tab).

Take Amazon's account at face value. The failure was a person acting on an agent's confident explanation of a system without being able to tell it was wrong. That's exactly the failure an AI SRE agent can produce on your rotation, and the defense is the same: a human who understands the system well enough to notice when an explanation doesn't fit.

Owning code means you can debug it

Most teams define ownership by assignment. A team is listed in CODEOWNERS, a service has an owning team in the catalog, an engineer approved the PR. Those records answer "who do we page?" They don't answer "can the person we page fix it?"

When humans wrote the code, the gap between those questions was small. Writing code is a slow, forced read of it. Agents removed the forced read, so the gap is now as wide as your team lets it get.

So treat ownership as something an engineer demonstrates, not something they're assigned. For a change on a paged path, the owner is the person who can answer three questions without the agent open:

1. How does this change fail, and what does that look like from the outside?
2. What's the first signal, which metric, log line or alert, that it's failing?
3. How do you roll it back, and does the rollback work if the agent tooling is unavailable?

Those three answers take five minutes to write when you understand the change. When you don't, they take much longer, and that's the point. The friction lands at merge time, when it's cheap, instead of at 3am.

The strongest case against this

The best objection: this is nostalgia with a checklist. The agent that wrote the code can explain it better than any human, and AI SRE tools will diagnose most failures faster than a sleepy engineer. Forcing humans to understand every paged change throttles the throughput gain that justified the agents. Before agents, plenty of teams paged people about code written by engineers who'd left years ago, and nobody demanded a comprehension test then.

Most of that is right. Agents will be faster at diagnosing common failures, and inherited code nobody understands is an old problem.

But there are two differences. The first is speed: a departed engineer's code went stale over years, while agent-written code can arrive already unfamiliar to everyone at a rate of dozens of changes a week. The second is who checks the diagnosis. An AI SRE agent explaining agent-written code to an engineer who understands neither is the Amazon pattern with more steps. The human in that loop needs enough understanding to say "that doesn't fit what I know about this service," or they aren't really in the loop.

Where this stops working

Most code doesn't need this test. Internal tools, prototypes and anything that can't page a person don't need it. If you apply the test to every change, it turns into a checkbox people tick without reading, and you're back to approvals that prove nothing. Scope it to paged paths.

Volume beats it eventually. If one service takes forty agent-written changes a week, nobody will hold all forty in their head. At that point the answer is better observability and smaller blast radius, not more reading. The test still helps by making the author write down the failure signal, even when no one remembers the details a month later.

Understanding decays. Someone who could explain a change in March may not be able to in September. That's why the drill below matters more than the merge checklist.

Small teams can't spread it. If two people are on call for everything, demanding deep understanding of all of it is unrealistic. Shrink the paged surface before you add process.

A pager-readiness policy you can adopt

This is one section to add to a PR template, plus one standing rule. Both are deliberately short, because a long checklist gets ticked without being read.

## Pager readiness (required if this change touches a paged path)

Owner on the rotation: @handle
(Must be someone who will be on call for this service this quarter.)

How this fails:
<!-- One or two sentences. What breaks, and what users or callers see. -->

First signal:
<!-- The alert, dashboard panel, metric or log line that shows it failing. -->
<!-- If no existing signal would catch it, add one in this PR. -->

Rollback without an agent:
<!-- Exact steps or command. Must work if agent tooling is down. -->

- [ ] The owner wrote the three answers above themselves,
      without pasting them from the agent's summary.

---

Standing rule: cold-debug drill, once per quarter per paged service

- Pick a recent agent-written change on the service at random.
- The next person up on the rotation gets 30 minutes, with no coding
  agent, to explain how it fails and walk through its rollback.
- Pass: they do it. Fail: the service has no real owner. Schedule a
  walkthrough or shrink what the service pages for, before the next drill.
- Track the pass rate per service. That number is your ownership metric.

The last checkbox does the most work. An agent will happily write a failure-mode summary, and it'll often be correct. On its own, that paragraph is worth very little. What the checkbox buys you is a human who understood the change well enough to write it. In the Anthropic trial, the developers who kept their understanding were the ones who asked the AI conceptual questions and resolved their own errors. They didn't just accept the output. Making the owner write the answers is the same move at team scale.

If you only do one thing this quarter, run the drill on your most-paged service and write down the result. A failed drill tells you more about who owns your code than CODEOWNERS does.