CODEOWNERS Was Built for Humans You Could Trust. Your Committers Are Now Agents.

Picture a tense PR review at 5pm on a Friday. Two engineers, one diff, eight hundred lines. The reviewer reads the change, asks about a subtle ordering issue, gets an answer that satisfies them, approves. They are not approving the change. They are approving the change plus the author — because part of what makes a fix safe to merge is the author's track record, the author's ability to defend a choice three months from now, and the author's reputation if this breaks production at 2am. Approval at its core is two signatures: one on the code, one underwriting the human attached to it.

Now substitute the second signature for claude-code <noreply@anthropic.com>. Nothing about the review process visibly changed. Everything about what review means did.

This is the quiet structural problem in repositories where most code is now agent-authored. Four pillars do the structural work of repo trust — and none of them break when the author identity flips, which is exactly the problem. They keep routing, attributing, approving, gating. But the load they were carrying is no longer there to carry. The scaffolding stays standing on a foundation that has been quietly removed.

The Four Pillars and What Each One Actually Encodes

Look closely at the trust scaffolding in any repository that ships to production. Every one of those four pillars encodes the same primitive.

CODEOWNERS routes review to people who know the code — the explicit encoding of "who maintains this corner of the system." The path-to-person mapping is a recall mechanism: when something changes in src/billing/, the people who built billing get pinged. They get pinged because they remember the constraints, the tradeoffs, the things that broke last quarter.

git blame attributes lines to a person. Blame is not a punishment system; it is a question-routing system. When the line above your bug looks suspicious, blame tells you who can answer "why is this here." The encoding assumes the named human still works on the team, still remembers, and still cares enough to explain.

Review approval is social proof that "another competent human read this and put their name on it." The "another human" is doing two jobs at once — verifying correctness and underwriting it. Reputation makes approval costly to give carelessly. The reviewer who approves a broken change pays for it in standing.

Branch protection rules make those approvals load-bearing. "Two approvals required, dismiss stale reviews, require CODEOWNERS review." Each rule is a structural enforcement of "this code does not move to production until N named humans have signed."

Strip the framing back and every pillar encodes the same primitive: a human author with reputation, recall, and social accountability sits upstream of every merge. That assumption was free for thirty years. It was correct because it was the only option.

Figure 1: Four pillars of Git trust, and the single assumption underneath them all. Each pillar encodes a different mechanism — recall, attribution, underwriting, gating — but they all rest on the same foundation: a named human author with reputation, recall, and social accountability.

What Breaks When the Author Is an Agent

Each pillar fails differently. The composite failure is what makes this hard to see.

CODEOWNERS still routes. When src/billing/handlers.ts changes, the billing owners still get pinged. But the change wasn't written by another billing person — it was written by an agent acting on a prompt the original engineer no longer has in their context. The CODEOWNER who gets pinged has to reverse-engineer the intent of a change they didn't author and didn't commission. This is the original problem CODEOWNERS was designed to solve — context drift during review — except now it appears on every PR instead of when someone wanders into unfamiliar code.

git blame still attributes. The attribution lands on claude-code or a service account or a developer who Tab-accepted in a Cursor session that closed two weeks ago. The question "why is this here" no longer has a person to route to. The agent has no memory of the session. The developer has no memory of the choice they didn't deliberately make. Blame becomes a pointer to nowhere.

Review approval still gates merges. But one of the two jobs approval used to do — underwriting — collapses. The reviewer is the only human in the chain. The "author" has no reputation to stake, can't be coached for next time, won't be embarrassed by a postmortem. All of approval's social pressure has migrated into the single reviewer's signature. The reviewer still owns the merge — we have argued this elsewhere — but they are now underwriting alone, where they used to share the load with a named author. Approval is no longer two signatures bracing each other. It is one signature carrying both loads.

Branch protection still requires N approvals. But the rule counts signatures; it cannot tell that one of them is no longer carrying anything. Two approvals from named humans was a meaningful constraint when PR throughput was bounded by typing speed and when both signatures were underwriting the change. It is a thinner constraint when an agent can produce plausible diffs faster than humans can review them — and the same two humans are still the bottleneck. The gate exists; the friction it used to apply has been arbitraged away.

Figure 2: Where the load goes when the author identity stops carrying it. The scaffolding stays standing — CODEOWNERS routes, blame attributes, branch protection gates — but the load they were sharing migrates onto the single reviewer signature, which is now doing the work of four.

The aggregate effect is that the audit trail compresses. Pre-agent, the trail was distributed: author, reviewer, CODEOWNER context, blame recall, social accountability. Post-agent, the trail is "an agent produced this; a tired human approved it." The first half does no work. The second half does all of it.

This is not an argument against agent committers. They are not going anywhere. It is an argument against assuming the trust scaffolding is still doing the work it appears to be doing.

Relocate Trust from Author Identity to the Delivery Contract

The fix is structural, not procedural. The trust signal needs to move from the named human attached to the change to the artifact bundle the change produces.

The open-source agentic CD knowledge base (beyond.minimumcd.org) names the unit precisely: the agent delivery contract. A change is no longer evaluated against the question "do I trust this author?" It is evaluated against the question "do these six artifacts agree with each other?"

The six artifacts, in authority order (highest to lowest):

1. Intent description — a human-authored statement of what this change should accomplish and why. The "why" includes a hypothesis: we believe this change will produce this outcome because of this reason. This is the artifact the human is on the hook for, regardless of who writes the code.
2. User-facing behavior — BDD scenarios describing observable outcomes. Humans define them; agents can draft them; the artifact does not change once it is approved.
3. Feature description (constraint architecture) — the musts, must-nots, preferences, and escalation triggers. Engineering owns it. The agent implements within those constraints, not against them.
4. Acceptance criteria — pipeline-enforced tests with known-good outputs. If they fail, the implementation is rejected regardless of how plausible the diff looks.
5. System constraints — non-functional requirements, security policies, performance budgets that apply to every change in the system.
6. Implementation — the actual code. The lowest authority in the stack. When it conflicts with anything above, the implementation changes.

Figure 3: What the gate is actually evaluating. Author identity asks a question the reviewer cannot answer about an agent. The delivery contract asks a question the pipeline can answer about the artifacts.

The framework's stronger constraint makes the implication concrete: agents implementing changes must not be the ones to promote them. The human gate is preserved — but the human is gating the contract, not the change author. The reviewer's question stops being "do I trust this person to have made this call." It becomes "does this implementation match the stated intent, satisfy the acceptance criteria, respect the constraint architecture, and pass the system rules." Those questions are answerable. The first one was never really answerable about an agent.

This is the same move that tests-as-spec made one layer deeper. We argued in Your Tests Are the Only Spec AI Reads that the artifact the agent persists across iterations is the test suite, not the ticket. The harness engineering frame sits underneath both: feedforward guides and feedback sensors form the artifact layer the agent operates on. The delivery contract is that argument extended to the merge gate: the artifact the reviewer evaluates should be the bundle the change satisfies, not the identity of who satisfied it.

How to Apply This

Four concrete moves your team can make this quarter without waiting for new tooling.

1. Rewrite CODEOWNERS for context, not for blame. Stop using CODEOWNERS as an attribution mechanism. Use it as a context routing mechanism. The CODEOWNER for src/billing/ should be the person who can read the intent description, the BDD scenarios, and the constraint architecture and tell you whether the change agrees with them. That may not be the person who wrote adjacent code six months ago. Route reviews based on who owns the contract, not who authored the file.

2. Promote the delivery contract above the diff in the PR template. A PR description today is usually a paragraph of what changed. Replace it with the contract: link the intent description, paste the relevant BDD scenarios, link the constraint architecture, and name the acceptance criteria the change satisfies. The diff becomes downstream context. The reviewer reads the contract first and the diff second. If the contract is empty or vague, the PR is not ready to review — the gate moves earlier.

3. Make branch protection require contract evidence, not just human-count. The default branch protection rule today is "N approvals from named humans." Add a layer: require that the contract artifacts exist, that the acceptance criteria pass, that the system constraints check passes, that any constraint flagged as a "must" in the feature description has a corresponding test. These are machine-checkable. They run automatically — the same principle as the structured quality gates we have argued for elsewhere. Human approval remains required, but it is now an approval of the bundle, with the contract evidence as load-bearing.

4. Log agent metadata as audit, not as blame. Git blame is dead as a question-routing mechanism for agent-authored code. Replace it. Per commit, log: which agent, which model version, which prompt or skill triggered the change, which session context was loaded, which evals and acceptance criteria passed. None of this lands in git blame. It lands in a structured audit trail attached to the commit. When something breaks six months from now, the question "why is this here" is answered by the bundle and the audit log, not by finding a human who remembers.

Figure 4: Branch protection as nested gates that evaluate the bundle, not the author. The human approval at the innermost layer is preserved — but the thing being approved is the contract evidence, not the named author's reputation.

The Bottom Line

CODEOWNERS, blame, review, and branch protection were built when the only available author was a named human with reputation. The scaffolding worked because the author identity was load-bearing. Agent-authored code does not break the scaffolding — it removes the load it was carrying and leaves the scaffolding standing on air.

The fix is not blocking agents. It is relocating trust from who wrote the change to what the change produces. The artifact bundle is machine-checkable. The author identity is not. The reviewer's job stops being a trust judgment about a person and becomes a verification that six artifacts agree with each other.

The next time you approve an agent-authored PR, ask which version of approval you are giving. The one that says "I trust this code." Or the one that says "I trust this person to defend this code in three months." The second one was the original product. It is the one that quietly stopped being available.