Set the Review Bar for AI-Generated Code — Provenance, Risk Tiers, and the Explain-Every-Line Rule

Workflow area: Policy & Governance · Tier: Core · Hands-on time: ~40 minutes

The volume problem is real: assisted teams open more PRs with bigger diffs, and reviewers either drown or rubber-stamp. The deeper problem is accountability drift — code nobody on the team can explain, merged because it compiled and the tests passed. A review standard is how you keep the speed and refuse the drift, and it takes one document plus a PR-template change to start.

When to use — and when not to

• Use it the moment AI assistants produce a meaningful share of merged codeif you had to guess whether that share is 10% or 60%, you are already late.
• Use it before any agent opens its first PRagent-authored changes without a declared review standard become the standard by default, and it will be "whatever got merged."
• Use it when review is visibly degradingcycle time climbing, "LGTM" on 800-line diffs, or reviewers privately telling you they cannot keep up.
• Skip the heavyweight version for throwaway spikes and prototypeslabel the repo experimental, keep the secrets rules, and let the rest go; standards that gate scratch work get ignored in production too.
• Skip it as a solo edicta review bar the senior engineers did not help set is a review bar they will quietly route around.

The recipe

1. 1.

   Add provenance to the PR template. One required line, four options: AI: none / assisted / substantial / agent-authored. Say out loud, and write into the standard, that the label routes review depth and is never used to evaluate people — the first time a label shows up in a performance conversation, honest labeling ends forever.

2. 2.

   Draft the risk-tier map with the model, then correct it with the team. Feed your repo layout to Claude:

   Copy

   You are helping an engineering leader tier a codebase for review
   rigor on AI-generated changes. Here is the repo structure and a
   one-line purpose per top-level module: [PASTE].
   
   Propose three tiers:
   - LOW: normal review applies (docs, tests, internal tooling).
   - ELEVATED: line-by-line review, author must explain the change.
   - CRITICAL: senior reviewer required; candidate no-AI zone.
   
   Flag as CRITICAL anything touching auth, payments, cryptography,
   PII handling, data migrations, or public API contracts. For each
   assignment give a one-line reason. Mark uncertain modules with
   [ASK TEAM] rather than guessing.
   

   Review the output with your tech leads — the model cannot know that utils/ secretly holds your billing math. Good output looks like:

   Copy

   CRITICAL — services/auth        session issuance; breach = incident
   CRITICAL — db/migrations        irreversible; agent PRs prohibited
   ELEVATED — services/checkout    revenue path, reversible via flags
   LOW      — docs/, tools/ci      [ASK TEAM] tools/ci touches deploy?
   

3. 3.

   Write the explain-every-line rule in plain words. Put this sentence in the standard verbatim: "You may merge code you did not type; you may not merge code you cannot explain." Reviewers get an explicit right to ask "walk me through this function" on any AI-labeled PR, and a stumbling answer sends the PR back — not as punishment, but because the author is the one paged at 2 a.m. when it breaks.

4. 4.

   Set the floors CI can hold. Coverage may not drop on ELEVATED and CRITICAL paths; PRs over a size threshold (say 400 changed lines) get a warning asking for a split; the provenance label must be present and parseable. Wire these as Danger-class checks so the standard enforces itself — pb-28 turns the full policy into CI gates; start here with these three.

5. 5.

   Declare the no-AI zones and publish. List the paths where AI-generated changes are prohibited outright (typically migrations, crypto, and anything a regulator or client contract restricts — see pb-33), put the whole standard in a one-page doc in the repo, walk the team through it in 20 minutes, and put a quarterly review date on it. Tiers move; zones shrink or grow; a standard nobody revisits is a standard nobody believes.

Make it yours

• Small team or startup: one page, three tiers, honor-system labels, and the explain rule — skip the CI wiring until pb-28. The rule that pays for itself immediately is the size warning: small teams drown in 1,000-line assisted PRs first.
• Large org or GCC: make the provenance label machine-readable (a PR template field, not free text), let client-facing repos inherit the stricter of your standard and the client's (pb-33), and align the tier map with your existing change-management classes so this reads as an extension, not a parallel regime.
• Heavily regulated environment: widen CRITICAL to everything in audit scope, require the reviewer to record the explain-walkthrough happened (a checkbox, not a transcript), and have compliance sign the no-AI zone list so it survives your next audit.

Quality check

• Labels match realityspot-check five PRs a month against tool telemetry at team level; if everything says none while assistant usage is high, the labels are dead and you should find out why before tightening anything.
• Review depth actually differs by tiera CRITICAL PR and a LOW PR getting the same 90-second review means the map is decoration.
• The explain rule gets invoked without dramayou should hear "walk me through this" in reviews monthly; hearing it never means fear, hearing it constantly means the tier map is wrong.
• Coverage floors are not gamedscan for assertion-free tests on AI-labeled PRs; models are excellent at generating tests that execute code and verify nothing.
• The quarterly revisit happensand produces at least one change, even if it is only re-tiering a module; an unchanged standard after a quarter of AI adoption is not stability, it is neglect.