SECOND reviews, not FORCED
Pairing with agents on code reviews, together
In addition to the manual reviews that I run (for taste, logic checks, business rules' changes that wasn't included in time), I also task agents to apply the following rubric for doing a second (see?) one.
AI disclaimer: OK, basically everything below other than my pick of SECOND and FORCED initialisms.
SECOND / FORCED — Code Review Rubric
A two-part framework for scoping a second AI review pass: SECOND names what's worth checking, FORCED names how the practice goes wrong if you're not careful.
🔎 SECOND — what to actually check
| Letter | Focus | Why a second pass helps | Prompt it like this |
|---|---|---|---|
| Summation | Does the diff match its own story (title, commit message, description vs. actual code)? | Catches quiet scope creep a re-summary alone would miss. | "Verify this description against this diff — flag any mismatch." |
| Exposition | Does the code explain its reasoning — comments, docstrings, PR narrative? | Reasoning quality is reviewer-dependent; a second reviewer asks different questions. | "Judge whether the why is explained, not whether the code reads well." |
| Clarity | Does the code itself read easily — naming, control flow, cognitive load? | "Clear to whom" varies by reviewer background/context. | "Review as someone new to this codebase." |
| Omnicompetence | Are all relevant domains covered — security, performance, concurrency? | Counters attention-anchoring on whatever's most visually salient. | "Only review this diff for [named domain] implications." — pick domains per diff |
| Neglect | What's absent that should be there — missing error handling, untested failure paths? | The only letter that hunts for omission instead of reviewing what's present. | "For each IO call/state mutation, confirm there's a failure path." |
| Design | Are the architectural choices and tradeoffs sound, including paths not taken? | Where reviewer judgment diverges most — real independent sampling, not redundant checking. | "What alternative approaches would you have considered?" |
Quick gut-check before running a letter: "Am I asking for a different judgment, or just re-asking the same question?" If it's the latter, skip it.
⚠️ FORCED — how it goes wrong
| Letter | The trap | The fix |
|---|---|---|
| Fake | Same model, same prompt, same context = the appearance of independent verification, not the substance. | Vary the model or at minimum the framing between passes. |
| Overstimulated | Six criteria's worth of commentary on every PR buries the signal. | Scale which letters fire to the size/risk of the diff — don't run all six by default. |
| Reckless | Bolting on a second pass with no clear purpose burns tokens, latency, and review time. | Decide which letter and why before the pass runs. |
| Careless | An unscoped "review this again" invites skimming the same surface issues. | Anchor the prompt to a specific claim, domain, or category of omission. |
| Expiring | Review value goes stale fast if the diff changes after review. | Re-check Summation and Neglect specifically right before merge — they're the most time-sensitive. |
| Decayed | The rubric survives past the point anyone remembers why it's shaped this way (e.g. Exposition/Clarity get "simplified" back into overlap). | Periodically re-ask why each letter still earns its place. |
🧭 Using this to prep a session
- Scope first. Look at the diff, pick only the SECOND letters that apply (rarely all six — see Overstimulated).
- Write one instruction per letter, using the prompt column above as a template — vague re-review prompts default to Clarity/Exposition-style surface feedback regardless of intent.
- Partition Omnicompetence explicitly — name the domains (security, performance, etc.) rather than asking for a generalist sweep.
- Vary the reviewer where you can — different model, or at least a materially different framing — to avoid the Fake trap.
- Re-run time-sensitive letters (Summation, Neglect) right before merge if the diff has changed since the first pass.
- Revisit the rubric itself occasionally — that's the Decayed check, applied to your own process.