# 15.9 Human approval, scaled by risk (/building-ai-workers/code-review/approval-scaled-by-risk) --- type: Document title: "15.9 Human approval, scaled by risk" description: "Low, medium and high tiers set by what a change touches, not by who wrote it, with code owners for sensitive paths and an approval that covers one commit." status: stable order: 315.09 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-02T18:33:52Z chapter: "15" part: III expert_status: builder-only concepts: [ "15.9" ] last_verified: 2026-10-31 sources: - id: anthropic-team-review title: "How the Claude Code team does code review (Anthropic, October 15, 2026, accessed 2026-10-31)" resource: https://claude.dev/blog/solving-code-review-at-anthropic/ - id: github-rulesets title: "About rulesets (GitHub, accessed 2026-10-31)" resource: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets - id: github-code-owners title: "About code owners (GitHub, accessed 2026-10-31)" resource: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners generated: at: 2026-11-02T18:33:52Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85 dirty: true ksor_version: 0.0.60 --- **In everyday life.** A bank lets a clerk approve a small refund alone, needs a supervisor for a larger one, and needs two signatures to change who can sign payments at all. The amount and the kind of action set the level. It does not matter how senior the person asking is. **What you will learn.** How to set the number of people who must approve a change, by what it touches. **Why it matters.** A small change to the wrong file can cost more than a large change to the right one. ### What sets the risk tier? What a change touches. In review, people's time is the limited resource ([15.4](why-review-changes.md)). So spend it where a mistake would cost the most. A **risk tier** says how many people must approve a change, and it is set by **what the change touches**, not by who or what wrote it. A change written by an agent and a change written by the senior developer get the same tier if they touch the same files. | Tier | Typical changes | Human approvals | | --- | --- | --- | | Low | Docs, notes, examples, and isolated new code behind a flag that is off, with tests showing the old behavior unchanged | None, once every required check is green | | Medium | Ordinary code and new tests | One | | High | Money, dates and rules, data, security, the review rules, the workflows, any change to an existing test | Two, one of them an owner of that area | ### What is a code owner? A **code owner** is a person or team named in a file, `CODEOWNERS`, as responsible for certain paths. With "require review from code owners" on, a pull request that touches `src/due-date.ts` cannot merge until its owner approves. The files that control review itself belong here: the workflows, `CODEOWNERS` and the review rules. A change that weakens the gate must pass the gate.[^github-code-owners] ### What keeps approval honest? Four rules. 1. **An agent's review never replaces a person's approval.** An agent can review and report. It is never one of the required approvers. That is a team rule, and the host cannot enforce it alone: an agent working through your signed-in account looks exactly like you. So in a team's CI, give an agent its own identity, such as a bot account or a token, with no right to approve. When it works through your account, as in this book's labs, never let it approve for you. Refuse any `gh` approval it proposes. 2. **The person who directed the agent is accountable.** On an agent-written change, they are one of the reviewers, and they answer the findings ([15.5](evidence-before-the-pr.md)). 3. **An approval covers one commit.** If a new commit arrives after an approval, the approval is stale. Turn on "dismiss stale approvals", so a person approves what actually merges. 4. **Outside changes get more care.** A pull request from a fork, or from someone outside the team, gets no secrets and no automatic AI review. A person reads it before any workflow with more access runs ([15.7](ai-review-on-every-pr.md) and [15.8](checks-that-block.md)). ### What can the host enforce? Less than the table asks. A tier table is a team's policy, and the host cannot enforce all of it. On a personal GitHub repository, a ruleset sets one approval count for every pull request to a branch. It cannot ask for none on docs and two on payment code. In an organization, a ruleset can also ask a team for approvals on chosen paths.[^github-rulesets] Code owners add a required reviewer for the paths they own. So the usual setup is one approval for every change, plus the code owner for every high-tier path. Low tier then means "no owner needed", and the second approval on high-tier work is a team rule the owner checks. Teams that need the exact counts add a check of their own that reads which paths changed. The case study's team does this with its own programs that sort changes into tiers. ### Does a flag lower the tier? Only sometimes. A change that turns on a flag is a policy decision, so it is high even when it is one line. A change that adds a new feature behind a flag that is off can be lower, but only when it is isolated, which means self-contained. Code behind a flag that is off still loads. A new import, a new package, a change to shared code or a data migration runs whether or not the flag is on. A data migration is a change to stored data. So the tier drops only when the new code is self-contained and a test shows the old behavior unchanged with the flag off ([15.10](after-the-merge.md)). The weekend rule changes the shared due-date engine, so it stays high, flag or not. **At work.** Brightline's tiers live in `REVIEW.md`, and its owners in `.github/CODEOWNERS`. ```text /.github/ @ana-brightline /REVIEW.md @ana-brightline /src/due-date.ts @ana-brightline @dave-brightline /tests/ @ana-brightline /scripts/check-*.sh @ana-brightline /package.json @ana-brightline /tsconfig.json @ana-brightline ``` The weekend pull request touches `src/due-date.ts`, `src/due-by-friday.ts` and `src/reconcile.ts`, so it is high. Ana opened it, and GitHub does not let anyone approve their own pull request. So Dave Kowalski, the other owner of `src/due-date.ts`, must approve. The `agent-speedup` pull request edits an existing test, so it is high too, whatever its size. A pull request that only fixes a typo in `NOTES.md` is low. Brightline's tier table says it needs no person once its checks are green. GitHub still asks for the one approval its ruleset sets for every pull request, but no code owner is asked. **In the case study.** The team uses the same three tiers, with zero, one and two approvals, and says the change sets the tier, not the author. Lighter review paths apply only to trusted authors. Outside contributors are the one exception to "the change sets the tier", as in rule 4. Any CI workflow file always needs a person. An agent's approval never counts as a person's. An approval covers one specific commit.[^anthropic-team-review] **The operating rule:** set the tier by what the change touches, name an owner for every sensitive path, and count only people's approvals, on the commit that merges. ![Three rungs, rising with how closely a change is checked. Low holds minor documentation and notes, with no per-change approval under a pre-approved policy. Medium holds ordinary code and new tests, with one reviewer. High holds money, dates, data, CI workflows, review rules and edits to existing tests, with two reviewers including the responsible owner. Notes say required checks pass on every tier, a flag that is off does not by itself mean low risk, and the tier depends on impact, not on who wrote the change.](img/risk-ladder.png) *Figure 15.15. The risk ladder. What the change touches sets the rung, and the rung sets how many people must approve.* **Practice it.** [Practice: approval scaled by risk](both-ai-vendors.md#practice-approval-scaled-by-risk), in your own tool, ten minutes. [^github-code-owners]: About code owners, GitHub. [^github-rulesets]: About rulesets, GitHub. [^anthropic-team-review]: How the Claude Code team does code review, Anthropic.