Helping the team stop reading every diff

Trust transfer is the change-management protocol that moves a team from reading every agent diff to approving on evidence, one loop at a time. Each loop passes through three stages, shadow review, sampled review and evidence-only, and enters each stage only on recorded evidence. A single production escape or material miss demotes the loop one stage.

Your team has read the evidence-instead-of-diffs argument and nodded. Then nothing changed: two seniors still read every line, the review queue is three days deep, and the one person who approved on evidence got blamed for a bug last month. People do not know when it is safe to stop reading, who answers if it goes wrong, or what their job is afterwards. This page is for the tech lead who has to answer those questions, and for the CTO who has to back the answers in writing.

What a trust-transfer rollout gives your team

A three-stage protocol per loop, with entry evidence a script can mostly check and rollback triggers that demote a loop without debate.
A team trust ledger (CSV), its four metrics, and a GitHub Actions job that draws one pull request in five for a full read.
A working agreement that states who is accountable for what, plus direct answers to the identity and accountability fears that stall the change.
Three copy-paste prompts: stage readiness, turning a miss into a check, and drafting the working agreement for your repository.

Why does a team keep reading every diff?

The load is real and measured. Faros AI’s Acceleration Whiplash report (April 2026; telemetry from 22,000 developers and more than 4,000 teams) found median time in review up 441.5%, and 31.3% more pull requests merging with no review at all. The second number is what an overwhelmed team with no sanctioned way to read less does: it skips review quietly.

The distrust is also real. Sonar’s developer survey (January 2026, more than 1,100 developers) found that “96% of developers do not fully trust AI-generated code, and only 48% always verify it before committing.” A memo that says “stop reading diffs” meets that distrust head on and loses.

So treat the shift as change management, not a policy switch. Trust is earned per loop, a repeatable class of change with its own trigger, oracle and stop condition, as defined in the one map. Dependency bumps can reach evidence-only while checkout feature work is still in shadow review, and both answers are correct at once.

What are the three trust stages?

Each stage changes one thing: what decides the merge, and how much code a human still reads. The escalation classes (authentication and authorization, money, schema, data migrations, changes to the oracle itself, and anything no check covers) are outside the protocol. A named person reads that code at every stage, as the escalation table sets out.

Stage	What decides the merge	What the reviewer reads on every pull request	Code reading	What the stage proves
Shadow review	The code read, as today	The evidence bundle first; the reviewer records a verdict, then reads the diff	Every pull request	Whether the evidence would have caught what the code read caught
Sampled review	The evidence	The evidence bundle	One pull request in five, drawn at random when it opens	Whether the evidence keeps holding when nobody knows which change will be read
Evidence-only	The evidence	The evidence bundle	None routinely; a 10-PR audit each quarter	That the loop runs at Level 4: a human reads evidence, not diffs

Shadow and sampled review are how a Level 3 loop earns Level 4: the team-scale version of the personal trust log on the evidence page, whose read-all, sampled and evidence-only stages map onto these three.

Which loop should go first?

Pick the loop where a mistake is cheapest to find and to undo: one that answers “yes” to all five questions below. Typical first loops are dependency bumps, flaky-test repair, copy changes and internal tooling.

Question	Why it matters
Does the oracle predate the agent, and is it outside the paths the agent may write?	An oracle the agent wrote or can edit proves nothing yet; build it first with oracle strength
Does the loop merge at least 20 pull requests a month?	Fewer, and the shadow stage takes a quarter to produce a verdict
Does a wrong answer surface in minutes or hours, not weeks?	Slow feedback hides escapes until after you have promoted
Is every change reversible by revert or feature flag?	Evidence-only needs a cheap undo
Does the loop avoid every escalation class?	Those classes never leave “always read”, so they cannot demonstrate the protocol

What evidence does a loop need to enter each stage?

Every criterion below is a record, not a feeling. The thresholds are team policy, not research findings: recommended starting values, consistent with the personal trust log. Lower them for trivial loops and raise them for anything a customer sees.

To enter	Entry evidence (all of it)	Who signs
Shadow review	The loop is named in `loops.yaml` with an owner. Every ticket in the loop carries acceptance criteria. Every pull request carries an evidence bundle, enforced by CI. Tests, CI and lint config are protected by `CODEOWNERS`. A 30-day baseline of change failure rate or revert rate exists for the loop.	Tech lead
Sampled review	At least 20 consecutive shadow pull requests, read by at least two different reviewers, with no material miss in the last 20. Every earlier miss is closed by a new check in the oracle. Evidence completeness is 100% over the window.	Tech lead
Evidence-only	At least 30 days in sampled review and at least 10 sampled reads with no material miss. No production escape in the loop over the window. Change failure or revert rate no worse than the baseline. The revert or flag rollback has been drilled once. The 10-PR audit from the one map passes. At 20 pull requests a month and a one-in-five sample, expect about ten weeks in sampled review.	Tech lead, with the CTO informed

A material miss is a defect or an unrequested behaviour change that the code read found, the evidence did not show, and that would have mattered in production. A naming nit is not a miss. A renamed public field is.

Record the stage in the loop register next to the level, so the stage is versioned and every change to it is a reviewed commit:

# loops.yaml (excerpt): add a trust block to each loop
- loop: dependency-bumps
  owner: platform-team
  level: L3
  trust:
    stage: sampled            # shadow | sampled | evidence-only
    entered: 2026-09-15
    signed_by: anna.kowalski  # tech lead
    sample_rate: 0.2          # one pull request in five
    baseline_revert_rate_30d: 0.03
    next_stage_criteria: 30 days and 10 clean sampled reads, no escape, revert drill done

Run the protocol week by week

Announce the protocol before the first loop moves. Publish the working agreement (template below), the stage table and the escalation list in one pull request the team reviews.
Start shadow review on one loop. Reviewers open the evidence bundle first, write a verdict in the ledger (approve or reject), then read the diff and record whether it showed anything the evidence did not. The merge still follows the code read, so production risk does not change yet.
Rotate shadow reviewers. Require at least two different people across the 20 pull requests; a stage one enthusiast earned alone is not the team’s trust.
Close every miss with a check before counting again. A material miss resets the count of clean pull requests to zero, and the loop does not accumulate a new run until the check that would have caught the miss is merged into the oracle.
Promote to sampled review in a pull request the tech lead approves. The tech lead changes trust.stage in loops.yaml in a pull request whose description links the ledger rows. From now on the evidence decides, and the sampling job below picks which pull requests get a full read.
Hold the retro at 30 days in sampled review. Review the four metrics, the sampled reads and near misses with the team. Promote only if every entry criterion holds on the record.
Audit evidence-only loops quarterly. Run the 10-PR audit from the one map. A failed audit demotes the loop exactly as an escape would.

Draw the sample before anyone sees the evidence

The sample only proves something if nobody chooses it. A reviewer who picks “the risky-looking ones” is testing their intuition, not the evidence. Draw the sample when the pull request opens and never re-draw it. This GitHub Actions workflow does that for same-repository pull requests (the default token is read-only on pull requests from forks):

name: trust-sampling
on:
  pull_request:
    types: [opened]
permissions:
  pull-requests: write
jobs:
  draw:
    runs-on: ubuntu-latest
    steps:
      - name: Draw one pull request in five for a full code read
        env:
          GH_TOKEN: ${{ github.token }}
          PR: ${{ github.event.pull_request.number }}
          REPO: ${{ github.repository }}
        run: |
          if [ $((RANDOM % 5)) -eq 0 ]; then
            gh pr edit "$PR" --repo "$REPO" --add-label "sampled-read"
          fi

Create the sampled-read label first: gh pr edit --add-label does not create missing labels. The ledger row records that the full read happened.

Two limits of the draw. Open agent pull requests with a GitHub App token or a personal access token: a pull request opened with the default GITHUB_TOKEN does not trigger other workflows, so it is never drawn. And the job labels pull requests from every loop, so the ledger counts a sampled-read label only for loops whose trust.stage is sampled.

Keep a team trust ledger

The ledger is one CSV file per repository, one row per reviewed pull request. Fill in escaped when an incident is traced back to a pull request.

date,pr,loop,stage,reviewer,evidence_verdict,code_read,material_miss,miss_note,escaped
2026-09-22,412,dependency-bumps,shadow,anna,approve,full,no,,no
2026-09-23,418,dependency-bumps,shadow,piotr,approve,full,yes,lockfile pinned a yanked version,no
2026-09-29,431,dependency-bumps,sampled,marek,approve,sampled,no,,no
2026-09-30,433,dependency-bumps,sampled,anna,approve,none,n/a,,no

Report its four metrics per loop and per stage, never blended; canonical definitions live in metrics frameworks.

Metric	Definition	What a bad value means
Miss rate	Material misses divided by pull requests whose code was read, per loop, per stage, over the window	The evidence is weaker than the code read; stay or demote
Escape rate by stage	Production defects traced to pull requests approved at a stage, divided by all pull requests approved at that stage, per month	The loop was promoted too early
Evidence completeness	Share of the loop’s merged pull requests carrying all four evidence artifacts	Approvals are running on trust again
Review time per pull request	Median time from ready-for-review to approval, per stage	The payoff: it should fall at each promotion, or the protocol is only adding ceremony

How do Claude Code, Codex and Cursor fit the protocol?

The protocol is identical in all three tools, because loops.yaml, the ledger, CODEOWNERS and the sampling job live in the repository. What differs is how the evidence bundle is produced and which tool may approve at evidence-only.

Save the evidence prompt from the evidence page as .github/prompts/evidence.md, then run it headless in CI or in your terminal. claude -p sessions start in Manual permission mode, so any shell command outside the allowlist is denied. The prompt runs the acceptance checks, so the allowlist names your test command next to git diff and git log; replace npm test with your repository’s own:

# Terminal or CI, from the repository root (Claude Code 2.1.283)
claude -p "$(cat .github/prompts/evidence.md)" \
  --allowedTools "Read,Grep,Glob,Bash(git diff *),Bash(git log *),Bash(npm test *)" \
  --output-format text > evidence.md

For a sampled-read pull request, claude ultrareview 431 runs the cloud-hosted multi-agent review of pull request 431. Treat it as a second reader beside the human, never as the sampled read itself. Ultrareview is billed per run after three free runs on Pro/Max (typically $5 to $25), and is not available to Zero Data Retention organizations or on Bedrock, Google Cloud or Foundry.

Codex needs two commands, because codex exec review --base does not accept a custom prompt (0.157.1 rejects the combination with the argument '--base <BRANCH>' cannot be used with '[PROMPT]'). Save the evidence prompt from the evidence page as .github/prompts/evidence.md, produce the bundle with plain codex exec, and run the review separately:

# Terminal or CI, from the repository root (Codex CLI 0.157.1)
codex exec --sandbox read-only -o evidence.md \
  "$(cat .github/prompts/evidence.md) Compare HEAD against main (git diff main...HEAD)."
codex exec review --base main -o review.md

The review takes its instructions from the review guidelines in AGENTS.md. Put the escalation classes and the loop names there, so both codex exec review and @codex review on GitHub name the loop and the class a change falls into.

Paste the evidence prompt from the evidence page into the agent before you open the pull request, and paste its output into the pull request description.

PR Routing & Approval “can approve low-risk PRs when your criteria are met” (checked on cursor.com on 2026-08-28). Turn that on only for loops at evidence-only, with criteria that any escalation class or sampled-read label blocks. See PR Routing & Approval in Cursor.

Copy-paste prompts for trust transfer

Decide whether one loop is ready for its next trust stage. Do not edit any file.

Read loops.yaml and trust-ledger.csv in the repository root. For the loop
named dependency-bumps:
1. State its current trust stage, the date it entered it, and the entry
   criteria for the next stage from loops.yaml.
2. From the ledger, compute over the current stage: pull requests reviewed,
   distinct reviewers, pull requests with a full or sampled code read,
   material misses, escapes, and the current run of consecutive clean rows.
3. Check each entry criterion one by one and mark it MET, NOT MET or
   UNKNOWN (no data). Quote the ledger rows behind every verdict.
4. List every material miss in the stage and whether a check that would have
   caught it has been merged (search the git log for its pull request).

End with one verdict: PROMOTE, HOLD, or DEMOTE, and the single missing piece
of evidence that blocks promotion.

A code read found a problem the evidence bundle missed. Ledger row:
2026-09-23,418,dependency-bumps,shadow,piotr,approve,full,yes,lockfile pinned
a yanked version,no

1. Read pull request 418's diff and its evidence bundle. Explain in two
   sentences why none of the four evidence artifacts (spec delta, acceptance
   results, oracle changes, runtime evidence) showed the problem.
2. Propose the smallest automated check that would have failed on pull
   request 418 and passes on main today: a test, a CI step, or a lint rule.
   Write it on a new branch.
3. Prove it: run the check against the pull request 418 commit and against
   main, and show both results.
4. Do not modify existing tests or CI steps. If the check needs one, stop and
   explain why instead.

Draft docs/trust-transfer.md, the team working agreement for approving agent
pull requests on evidence. Read CODEOWNERS, loops.yaml, AGENTS.md or
CLAUDE.md, and the CI configuration first.

Use the section headings of the template below, and fill each one from
this repository: the loops and their current trust stage, the escalation
classes with the CODEOWNERS paths that enforce them, and the CI job that
enforces the evidence bundle. Where a control does not exist yet (for example,
tests are not protected by CODEOWNERS), write MISSING and the one-line change
that would add it. Do not edit any file except docs/trust-transfer.md.

Who is accountable when nobody read the code?

This question stalls more rollouts than any tool. Answer it in writing before the first loop moves and have the CTO sign it: a tech lead cannot promise protection from blame the organization has not agreed to.

DORA’s guidance on the AI capabilities model makes the same point about policy in general: “Ambiguity creates risk. A clear policy provides the psychological safety developers need to experiment effectively.” (Nathen Harvey and Allison Park, Google Cloud blog, 10 December 2025.)

Adopt this working agreement as-is and edit the names:

# Working agreement: approving agent pull requests on evidence

## What an approver answers for
- The evidence bundle was complete: spec delta, acceptance results, oracle
  changes, runtime evidence.
- No escalation class was touched, or the named code owner read that code.
- The approval follows the loop's current trust stage in loops.yaml.

## What an approver does not answer for
- A defect that the required evidence could not show. That demotes the loop
  and adds a check. It is not raised in performance reviews.

## Who owns the stage
- The tech lead signs every promotion in loops.yaml.
- Anyone on the team may demote a loop by opening a pull request with the
  reason. Demotion needs no approval and is merged the same day.
- The CTO owns the escalation list and the risk-class policy.

## What never changes
- Authentication, money, schema, migrations and oracle changes, and any code
  no check covers, are read by a named person at every stage.
- Every merged pull request has a named human approver.

The asymmetry matters. Promotion is slow and signed; demotion is fast and anyone may trigger it, so a skeptical senior keeps a brake they can pull without asking.

What do people fear, and what does the protocol do about it?

Say the fears out loud in the kickoff. Each has a true part, and the protocol answers that part.

The fear	What is true about it	What the protocol does
“If I approve without reading and it breaks, it is on me.”	Today, it often is: an approver of a skimmed diff has nothing to point to.	The working agreement moves accountability to the evidence the approver checked, and makes a protocol miss a loop demotion, not a personal failure.
“My value is that I know this code.”	Deep knowledge of the system still matters, and it erodes if nobody reads code. Anthropic’s internal study (Saffron Huang and colleagues, 2 December 2025) calls this the “paradox of supervision”: oversight needs the skills that over-delegation erodes.	Seniors own the escalation classes, the sampled reads and the oracle. Keep one full read a week in a loop you own; your craft and career covers which skills to keep deliberately.
“I became an engineer to build things, not to approve them.”	The same Anthropic study found some engineers’ work had shifted “70%+ to being a code reviewer/reviser rather than a net-new code writer”.	The protocol exists to reverse that drift: less time reading diffs, more time writing specs, oracles and checks. Track review time per pull request to show it happening.
“Juniors will never learn the codebase.”	They learn less if nobody reads code.	Put juniors on shadow reads alongside a senior; comparing their evidence verdict with the code read teaches the system. See growing junior developers.
“The agent will make its own tests pass.”	It can, if it may edit them.	Oracle changes are an escalation class at every stage, and `CODEOWNERS` enforces it. See protecting the oracle.
“This is about cutting headcount.”	Leaders rarely say otherwise unless asked.	The CTO states in the working agreement what the freed review time goes to. If that cannot be said honestly, the rollout will stall.

For the conversations that go beyond the kickoff, see bringing skeptics and senior engineers along.

When do you roll a loop back a stage?

Demote on the first occurrence of any trigger below. Do not wait for a pattern; discuss causes in the retro.

Trigger	Demote to
A production escape traced to a pull request approved at the current stage	One stage down
A material miss in a sampled read	Shadow review
An oracle file changed without code-owner approval	Shadow review, and investigate how it merged
A material change to the loop’s harness: a different model, a rewritten rules file, a new skill or MCP server in the loop’s path	Evidence-only loops drop to sampled review for the next 10 pull requests. Sampled loops reset their clean-read count.
Two demotions of the same loop in one quarter	Shadow review, and fix the oracle before counting again

A single pull request without a complete evidence bundle is not a trigger: read it in full, log it, and demote only if it happens twice in a window.

Change trust.stage in loops.yaml in a pull request that links the ledger row or incident. Merge it the same day.
Tell the team where reviews happen, in one sentence: the trigger and the new stage.
Write the check that would have caught it with the “turn a miss into a check” prompt, and merge it into the oracle.
Restart the count for the lower stage from zero.
Write a blameless note in miss_note or the incident record: which evidence artifact was missing or weak, not who approved.

What breaks when a team stops reading diffs?

Stages get promoted by the calendar. Recovery: reject a promotion pull request that does not link the ledger rows meeting each criterion.

The sample is chosen after looking at the evidence. Recovery: only the sampling job assigns sampled-read; any other read is logged as an extra read.

Seniors keep reading everything in private. Shadow review never ends and the queue does not shrink. Recovery: timebox shadow review per loop (six weeks is a reasonable ceiling), and ask in the retro what evidence would let each senior stop. The answer is usually a missing check.

One loop’s success is generalized to the team. Recovery: every loop enters shadow review on its own evidence; the one map reports a team as a distribution across loops.

The evidence bundle becomes a paraphrase of the diff. Recovery: CI rejects an acceptance line without a file:line or a command and its exit status; the evidence bundle page has the check.

A defect is pinned on the approver. One blame conversation undoes months of trust-building. Recovery: the tech lead restates the working agreement, the loop is demoted instead, and the team writes the missing check.

Reviews speed up but incidents rise. Faros AI’s April 2026 data shows the pattern at industry scale: epics completed per developer up 66.2% and incidents per pull request up 242.7%. Recovery: the escape rate by stage is the gate. If it rises above the baseline, demote, whatever the review-time chart says.

Where to go next with trust transfer

Reading evidence instead of code The prerequisite: the four artifacts a reviewer reads and the classes that stay read.

The evidence bundle The pull request contract and the CI check that fails an incomplete one.

How strong is your oracle? Build the oracle a loop needs before it enters shadow review.

Running the review queue Keep pull requests moving while loops sit at different stages.

Growing junior developers The next step in the tech-lead track: learning when agents write the code.

Governance and autonomy Where the CTO writes down risk classes and the escalation list once.

Frequently asked questions

What are the stages of trust transfer?

Three stages, run per loop. In shadow review the code read still decides the merge, but the reviewer records a verdict from the evidence first. In sampled review the evidence decides and one pull request in five, drawn at random when it opens, is read in full. In evidence-only the evidence decides and code is read only for escalation classes and audits.

How do you roll back a trust stage?

Demote the loop one stage on the first production escape or material miss, record the reason in loops.yaml, write the check that would have caught it, and restart the counter. Demotion needs no approval; promotion needs the tech lead's signature.

Who is accountable when an evidence-approved change breaks?

The approver answers for checking that the evidence was complete and that no escalation class was touched. The tech lead answers for the stage decision. A defect the required evidence could not show demotes the loop and adds a check; it is not held against the person who approved.