senior-code-review

Senior code review

One review that runs several complementary passes over a change, then applies judgement and stops at the human gate. The point is an independent read, as honest as you can make it, that informs the human's call without ever substituting for it. This is the operational companion to running-a-review and review-voice; the never-approve rule and the human gate are the whole point, not a nicety.

The one idea to start with: the reviewer reads cold and reports. It doesn't approve. A human posts, and the team's approval gate clears a merge.

Run it in this order

1. Read cold. Form the read with nobody's findings in front of you and no conclusion pre-loaded, no statement of what you're supposed to confirm. The change's own description and ticket are fair to read, since they're claims to verify; what you refuse is a briefing that tells you the verdict to reach. Brief a reviewer with a conclusion and all you get back is that conclusion.
2. Read the checked-out code, not just the diff. First confirm what actually changed against the base (the live diff), so you aren't reviewing already-merged or phantom content (a rebased-empty branch reads as real files but is a no-op diff). Then check the branch out into a throwaway worktree and read the real files for context. The load-bearing facts are usually invisible in the patch: a default that silently coerces a missing value to zero, an access grant the change leans on, a dependency version that shifted under it. The main clone is a read-only reference; never mutate it.
3. Walk the four passes below to gather candidate findings.
4. Reconcile against the live thread. Re-fetch the head (the author may have pushed, even fixed the thing) and read the existing comments. Check the commit each approval and each automated finding was made against. Don't raise an earlier approval as stale: whether it survives a push is the gate's configuration, not a finding. Do raise a substantive change that landed after an approval, a rework rather than a rebase, since the approvers signed off on something else. A bot finding computed on an older commit may be moot, so verify it against the live diff before repeating it. Already raised and open? Add weight only if you have something new. Already fixed on a newer commit? Drop it. Already dispositioned as by-design? Engage the reasoning or accept it. "Do nothing" is a valid outcome.
5. Work it finding by finding, with the human running the review. Surface each finding as it clears: what it is, the evidence, whether it blocks. Size it and decide together (drop / nit / follow-up ticket / hold / fold in), then the next. The agent proposes and the operator disposes; any back-and-forth with the author is the human's, downstream of this.
6. Assemble the survivors into one review, then re-voice it into the posting reviewer's register before it goes out (see review-voice); the raw findings as gathered aren't postable as-is. If nothing survives, add nothing, just recommend approval.
7. Stop at the gate. Recommend hold or approve; the human posts and holds the binding approval.