Writer Session, Reviewer Session
Run two parallel sessions on one version-controlled project: one builds, the other — with fresh context — reviews. The docs are explicit about why it works: a fresh session isn't attached to code it didn't write, so it critiques honestly where the author session defends.
Why it works
The docs state it plainly: a fresh context reviews better because it isn't attached to code it just wrote. Two parallel sessions on one version-controlled project — one builds, one reviews cold — recreate the author/reviewer split real teams pay two salaries for. The builder defends; the fresh session just reads what's actually there.
How to do it
- Precondition: the project is under version control (isolated copies per session come free).
- Session A (name it 'builder — feature X'): builds the feature as usual.
- When A says done, open Session B fresh: 'reviewer — feature X'.
- Give B the cold brief: 'review the latest changes: real errors, risky assumptions, broken cases.'
- Bring B's findings back to A to fix — or let B fix directly if they're small.
- Rename both sessions immediately; two unnamed parallels become indistinguishable within the hour.
Copy this
You're the reviewer; a different session wrote the recent changes. Review the latest diff cold: real errors, unhandled cases, assumptions that could be wrong. You didn't write this — don't defend it.
What to watch for
- Asking the AUTHOR session 'are you sure it's good?' gets author-grade reassurance — the value is in the fresh context, not in asking twice.
- Without version control, parallel sessions can genuinely collide in the same files; the isolation is a feature of the baseline, not of sessions per se.
Sources