Chapter 1 · The Ratchet & the Practice Loop · Lesson 1.6
Cross-Agent Review
The win: a second agent catches what the first one missed. Never let a model be the only judge of its own work.
- 0.1-0.3 · Sprint Zero (models, harness, spec-driven dev)
- 1.1 · The ratchet
- 1.2 · CLAUDE.md as a pilot's checklist
- 1.3 · Hooks, not instructions
- 1.4 · Spec before code
- 1.5 · Context firewalls & subagents
- 1.6 · Cross-agent review
The core move
Your agent finishes a task and says it's done. Do you believe it? The habit of this lesson is simple: after one agent finishes, run a second, independent agent whose only job is to review the work. A fresh session, ideally a different model, that never saw the original conversation - it just reads the result and hunts for what's wrong.
Why not let the same agent check itself
The tempting shortcut is to ask the same agent "are you sure that's right?" It will happily say yes. A model grading its own output is weak, because it shares the blind spots that produced the bug in the first place - the same reasoning that wrote the mistake is the reasoning now checking for it. So you separate the maker from the judge. Addy Osmani frames this as the generator / evaluator split - "GANs for prose": one agent writes, a separate evaluator critiques.
That separate pass is what the course calls cross-agent review - and per Osmani, keeping the writer and the critic apart is what keeps the critique honest (Agent Harness Engineering).
Diversity beats repetition
Here's the part people miss: running the same model twice mostly just repeats itself - it lands on the same conclusions and the same blind spots. A different model, or even the same model given a fresh, differently-worded prompt, catches different failure modes. The value of the second pass comes from it being genuinely independent, not from it being another turn.
Tests are the cheapest reviewer
Not every review needs a whole second agent. The cheapest automated reviewer you have is a test suite. Writing tests first and running them gives you a mechanical second opinion on every single change - no judgement call required, no extra model to pay for. This is exactly where hooks (Lesson 1.3) earn their keep: a hook that runs the tests after every edit turns "did it work?" into an automatic answer. Simon Willison's pattern guide highlights the same two habits - "red/green TDD" and "first run the tests" (Agentic engineering patterns). One reported result: a test-and-verify loop cut regressions by about 70% on a standard benchmark (per My Experiments With AI).
This closes the ratchet loop
Back in Lesson 1.1 we said a ratcheted fix has three homes: a rule, a hook, or a reviewer for the checks that need judgement a script can't make. The review pass is that reviewer - the "needs judgement" home. And it does more than catch bugs: every real failure it surfaces feeds back into the rest of the harness - a new rule (1.2), a new hook (1.3), or a sharper spec (1.4). That's the flywheel: the model does not get smarter, the harness does.
- Fresh and independent - a new session, ideally a different model from the one that did the work.
- Give it only the diff and the spec - the changed code plus your done-when criteria. Do not paste the original chat; the review must not inherit the maker's reasoning.
- Point it at the right target - ask it to hunt for correctness bugs and unhandled edge cases, not style nits.
- Feed real findings back - each true miss becomes a durable fix: a rule, a hook, or a test. That's the ratchet turning.
Check yourself
A second review agent should be -
The value is independence: a fresh agent (ideally a different model) that never saw the original chat catches failures the first one is blind to. The same agent shares those blind spots.
To catch different failures, the reviewer should be -
Same model twice mostly repeats itself. A different model - or a differently-prompted agent - detects different failure modes. Diversity, not repetition, is what makes the second pass worth running.
The cheapest automated reviewer is -
Tests give a mechanical second opinion on every change with no extra model and no judgement call. Wire them into a hook (Lesson 1.3) and the review runs itself.
Do this now (5 min)
Next time your agent finishes a task, don't just accept it. Instead:
- Open a fresh session - ideally a different model.
- Paste only the changed code plus your Done-when criteria from Lesson 1.4. Not the original chat.
- Ask it to find correctness bugs and missed edge cases.
Note one thing the first agent missed. That miss is a candidate for a new rule or hook - which is the ratchet turning one more notch.
You've completed Chapter 1
One breath, the whole loop: the model is a commodity, the harness is your edge. The ratchet turns every failure into a durable fix, and you place that fix in the cheapest home that holds - a rule when the agent just needs to know, a hook when it must be enforced, a spec when the decisions must be nailed down first, clean context when the window is the problem, or a review when the check needs judgement. Each fix compounds: it survives restarts, new sessions, and teammates, and every miss you catch tightens the harness one more notch. Now go keep ratcheting on real work.
Go deeper
Primary source (read this): My Experiments With AI - Why the Harness Wins, sections P5/P6 on running a second agent and the test-and-verify loop.
Secondary: Addy Osmani - Agent Harness Engineering, on the generator / evaluator split and why the maker shouldn't be the judge.
Wisdom (test it on people): the HumanLayer community - a good place to pressure-test your two-agent workflow against how other teams actually run review.