CODEOWNERS for the Fleet: Review Routing When the Author Is an Agent

Your CODEOWNERS file encodes an assumption so old nobody remembers making it: the author of a diff knows whose turf they're on. A human engineer changing the billing service knows they're in billing territory. They scoped the change to their team's directories on purpose, and if they had to touch another team's code, they walked over — physically or on Slack — and gave a heads-up before the review request ever fired. Path-based review routing works because human authors pre-route their own changes.

Agents don't do this. An agent told to "migrate every deprecated logger call" sweeps the whole repository in an afternoon and produces a diff touching four hundred directories. GitHub dutifully consults CODEOWNERS, matches every glob, and fans the review request out to forty teams simultaneously.

Nobody asked those teams whether they wanted this change. Nobody warned them it was coming. And the "author" requesting their approval isn't a colleague they can grab for context — it's a bot account acting on behalf of someone in a different org who may not even know which teams got paged.

More than one in five code reviews on GitHub now involve an agent. The routing layer underneath those reviews was designed for a world where authorship implied territorial awareness. That world is gone, and the failure isn't graceful: it's a ten-thousand-file codemod frozen behind a hundred pending approvals, and forty team queues clogged with changes no human chose to make.

The hidden contract in path-based ownership

CODEOWNERS looks like a routing table, but it's really one half of a contract. The visible half says: changes under /payments/ need approval from @payments-team. The invisible half says: whoever authors a change under /payments/ understands they are entering payments territory, has a reason to be there, and has scoped the change accordingly.

Human authors honor the invisible half without thinking about it. Their changes cluster around the code they know, which is the code their team owns, which means most PRs match one or two ownership rules and land in queues that expected them. Cross-team changes are rare enough that the coordination overhead — a heads-up message, a design doc, a meeting — gets paid case by case.

Even under purely human authorship, this contract was fraying at scale. Large monorepos already suffer from unowned files (in some audits, roughly one in eight files matches no ownership rule), overlapping globs that page multiple teams for one change, and approval deadlocks when the one person who can sign off on a shared file is on vacation. Teams describe review routing in big monorepos as "inbox roulette."

Agents don't fray the contract; they void it. An agent has no concept of turf. It optimizes for task completion across whatever files the task requires, and its natural diff shape is horizontal — thin slices across the entire codebase — rather than the vertical, team-local shape CODEOWNERS was tuned for. Every glob matches. Every team gets paged. The routing table executes perfectly and produces a result nobody wanted.

This lands on top of a review system already past capacity. The 2025 DORA report found AI adoption now correlates positively with delivery throughput but still correlates with instability — more change failures and more rework — precisely because generation accelerated while verification didn't. Engineering-metrics studies of high-AI-adoption teams show pull request counts nearly doubling while review times grow by around 90% and PR sizes balloon. Review was the bottleneck before the fleet arrived. The fleet turns a bottleneck into a routing failure.

The author is a pair now: route by the sponsor, not the paths

The deeper problem is that "author" no longer names one party. Every agent-generated diff has two: the agent that wrote the code and the human who launched it. Git can already represent this split — the commit author versus the committer, Co-authored-by: and Generated-by: trailers, bot identities on the PR — and emerging practice treats these trailers as a forensic audit trail for exactly this reason. Recent work on agent accountability frames it as an identity problem: for any agent acting in your systems, you must be able to trace back to the account that deployed it, or you have an accountability gap.

Review routing should consume this identity, and today it doesn't. CODEOWNERS routes on one signal — which paths changed — because for human authors, paths were a proxy for everything else: intent, scope, accountability. For a principal-agent pair, the paths tell you almost nothing. The signal that matters is the sponsor: which human initiated this, under what mandate, with what track record.

Concretely, sponsor-based routing changes three decisions:

• Who reviews first. The sponsor reviews before anyone else is paged. GitHub's own guidance on agent PRs is blunt about this: the human who launched the agent is responsible for validating the agent captured their intent, editing the description, and reviewing the diff before requesting anyone's time. A review request from an agent whose sponsor hasn't approved yet should be treated as unsent.
• Who is accountable after merge. When the change regresses something three weeks later, "the agent did it" is not an answer. The sponsor's name should be on the blame layer — queryable, so an incident responder can go from a bad line to a human in one hop, not through a bot account to a task ID to a person who left the team.
• How much scrutiny the diff gets. A sponsor with a hundred clean agent-assisted merges in this area is a different risk than a first-timer pointing a fleet at code they've never touched. Human reviewers earn trust per person; sponsors should earn it per person-with-agent, and routing should read that trust level.

None of this removes path-based ownership. Teams still need to control what enters their territory. It means path matching becomes one input to routing rather than the entire algorithm — the question shifts from "which files changed" to "who is driving, and do they have standing to change these files."

Autonomy budgets: ownership rules that answer "at what review tier"

Once the sponsor is a first-class routing input, the second upgrade follows: ownership rules should specify not just who approves but how much autonomy agent-authored changes get in each part of the tree. Call it an autonomy budget — a per-directory declaration of what review tier agent diffs must clear.

A sketch of what teams are converging on:

• Generated and mechanical zones — lockfiles, generated clients, formatting-only churn: agent diffs merge on green CI plus the sponsor's approval. No team review requested.
• Standard application code: agent diffs get automated review first (a machine pass for duplication, CI gaming, and hallucinated correctness), then one human from the owning team reviews the judgment calls, not every line.
• Load-bearing zones — auth, billing, migrations, anything security-sensitive: full team review, agent authorship prominently flagged, no auto-merge regardless of the sponsor's track record.

This isn't hypothetical machinery. Cloudflare's internal review orchestration already classifies every merge request into risk tiers — trivial changes get two automated reviewers, mid-size changes four, large or security-sensitive changes seven-plus — and ran 131,000 reviews in a month at a median cost under a dollar and under four minutes. The tiering logic exists and works; what most organizations haven't done is wire it into ownership, so that the tier is a property of the territory rather than a global setting.

The autonomy budget also gives teams a dial they currently lack. Today a team's only lever against agent traffic is social — complain until people stop pointing agents at your directories. With ownership-level budgets, a team that just got burned can drop its tier for a quarter, and a team drowning in trivial approvals can raise its threshold and delegate the mechanical tier to CI. The DORA finding that AI amplifies whatever engineering system it lands in cuts both ways here: teams with strong automated quality gates can safely accept high agent autonomy; teams without them shouldn't pretend otherwise in their ownership rules.

The codemod deadlock, and why sampling beats sign-off

Now, the failure mode that makes all of this urgent: the repo-wide sweep. An agent executes a ten-thousand-file mechanical migration — a renamed API, a logger swap, a lint rule enforced everywhere. Under blanket CODEOWNERS rules, that diff requires approval from every team whose glob it touches. A hundred approvals, each from a queue with its own latency, any one of which can stall the whole change. Meanwhile the diff is rotting: every day it waits, the codebase moves underneath it, and the agent (or its sponsor) rebases and re-pages a hundred queues again.

The deadlock exists because blanket rules can't distinguish one decision applied ten thousand times from ten thousand decisions. A mechanical codemod is the former. The thing that deserves review is the transformation — is this rewrite rule correct? — plus evidence it was applied faithfully. That review takes one team an hour. Reviewing each application independently takes a hundred teams a week and produces no additional safety, because reviewer number sixty-three looking at their team's fifteen renamed call sites has no information the first reviewer lacked.

The escape is to review the codemod the way you'd review a data pipeline, not a hand-written patch:

• Approve the transformation once. A designated owner — platform team, or the owners of the API being migrated — reviews the rewrite rule and its test evidence and signs off on the pattern.
• Verify application by sampling. Randomly sample changed sites across teams' territories; if the sample is clean and CI is green everywhere, the remaining sites inherit approval. Statistical confidence, not per-team sign-off.
• Give affected teams a veto window, not an approval gate. Notify every owning team with a deadline: object within N days or the change lands in your directories. Silence means consent for mechanical tiers; it must never mean consent for load-bearing ones.

Splitting the sweep into per-team PRs — the common workaround — is strictly worse than this: it multiplies the coordination surface, guarantees the migration lands half-finished, and leaves the codebase in the mixed state migrations exist to eliminate. The unit of review has to change, because the unit of authorship already did.

Rewrite the contract before the fleet does

The uncomfortable summary: CODEOWNERS still answers "who must approve changes to these files," but agents broke the assumptions that made that the right question. The right questions now are who is sponsoring this change, what autonomy does that sponsor's agent get in this territory, and is this one decision or ten thousand — and today's tooling answers none of them natively, so the answers live in tribal norms, bot-account conventions, and ad-hoc exemptions.

You can get most of the way there with what exists now. Require every agent PR to carry its sponsor's identity in trailers and treat sponsorless agent PRs as spam. Make sponsor self-review a merge-blocking check, not an etiquette suggestion. Encode autonomy tiers as branch-protection differences between directories, even crudely. Stand up a codemod lane with pattern-level approval and sampled verification before the first ten-thousand-file sweep hits your org, because designing it during the deadlock is miserable.

The teams that treat review routing as infrastructure — versioned, load-balanced, aware of who's driving — will absorb fleet-scale authorship and convert it into throughput. The teams that keep pretending every PR author is a human who knows whose turf they're on will discover that a routing table executing its rules perfectly can still deadlock an entire engineering org. The fleet is already opening pull requests. The ownership file it's hitting was written for someone else.