Orchestrator Implementor Review Loop - Code Review with tmux Claude Code Sessions
The Orchestrator-Implementor-Review Loop
Running one Claude Code instance is helpful. Running three with distinct roles - orchestrator, implementor, and reviewer - is a workflow that catches bugs before they reach your main branch.
The Three-Session Setup
Open three tmux panes, each running a separate Claude Code instance:
tmux new-session -s orchestrator
tmux new-window -t orchestrator -n implementor
tmux new-window -t orchestrator -n reviewer
The orchestrator breaks tasks into subtasks and feeds them to the implementor. The implementor writes the code. The reviewer reads the diff and flags issues. You supervise the loop.
Why Separate Sessions Matter
A single Claude Code session trying to plan, implement, and review its own code suffers from confirmation bias. It wrote the code - of course it thinks it's correct. A separate reviewer session starts fresh, reads the diff with no context about shortcuts taken, and catches the gaps.
The orchestrator session maintains the high-level plan. It doesn't get lost in implementation details because it never sees them. It only cares about whether subtasks are complete and what comes next.
Making the Loop Work
The practical workflow looks like this:
- Orchestrator writes a task spec to a shared file
- Implementor reads the spec and writes code
- Implementor commits to a feature branch
- Reviewer runs
git diff main..featureand writes feedback - If feedback exists, implementor addresses it
- Orchestrator moves to the next task
The shared coordination happens through the filesystem - markdown files for specs, git branches for code, and a simple status file tracking what's done.
When to Use This
This is overkill for a quick bug fix. It shines on larger features where you'd normally do multiple rounds of PR review anyway. The review loop runs in minutes instead of waiting for a human reviewer's schedule.
Fazm is an open source macOS AI agent. Open source on GitHub.