Pair Programming
The Pair Programming pattern binds two sessions to a shared workspace (workspaceOverride) where one acts as the Driver (editing files, implementing logic) and the other acts as the Navigator (reviewing code, checking architecture, guiding steps) in a turn-based collaborative loop.
Driver-Navigator Loop
┌────────────────────────────────────────────────────────┐
│ Shared Workspace │
│ (Same Workspace Override) │
└──────────────────────────┬─────────────────────────────┘
┌─────────────┴─────────────┐
▼ ▼
[ Driver Session ] ◄────────► [ Navigator Session ]
- Write code and implement - Review design, guide structure
- Direct file modifications - Provide feedback (turn-based)
5-Stage Workflow
- Session Selection: Inspect existing child sessions and reuse an Idle Driver/Navigator session with the matching assistant ID and exact workspace contract through
agent__messageToSession. Usereset=truewhen beginning a fresh pairing task. Start a new session only when no compatible pair member exists or the required role/workspace differs. - Workspace Configuration: Ensure both sessions share the exact same
workspaceOverridedirectory. - Assign Roles: Allocate the Driver role to a code-generation model and the Navigator role to an analysis-focused model.
- Turn-based Interaction:
- The Driver implements a section of code and writes a summary of the edits for the Navigator.
- The Navigator runs
view_fileorgit diffon the workspace, checks for issues, and sends feedback/next instructions to the Driver.
- Role Rotation: Swap roles when moving between tasks (e.g., swapping to write test suites). See role-rotation.md.
- Validation: Run the final project test pipeline to verify correctness.
🛠️ MCP Tools Guide
- Turn Coordination: The parent session collects the Driver's changes summary and forwards them to the Navigator via
agent__messageToSessionto invoke the next turn, maintaining a lock-step loop.
References
- Role rotation
- Turn protocol
- Diff review checklist