Pair programming with a human partner has well-established patterns: driver writes code, navigator reviews and guides, they swap regularly. With Claude Code, the same model applies — but the dynamics are different enough to need some adjustments.
You as navigator, Claude as driver
The most productive setup for me: I think, Claude types. I tell Claude what to build and why, Claude figures out how and writes it, I review and steer.
This maps to: "Here's the task. Here's the relevant context. Here's what done looks like. Start on [specific piece]."
The navigator role means I stay engaged — I'm not watching Claude work, I'm actively reviewing each piece and deciding what's next.
You as driver, Claude as navigator
Useful when you're in a domain you know well and want to write the code yourself, but want a second opinion in real time.
Setup: "I'm going to write this function. After each section, tell me if you see problems or better approaches. Don't rewrite it — just flag things."
The "don't rewrite it" constraint is important. Without it, Claude takes over and you're back to navigator.
Getting Claude to ask instead of assume
The biggest difference from human pair programming: Claude will make assumptions and charge ahead without flagging them. Human pairs stop and ask when something's unclear. Claude guesses.
Fix this at the start of each session:
When you're about to make a decision that could reasonably go multiple ways,
stop and ask me instead of picking one. I'd rather answer a question than
fix a decision I would have made differently.This changes the interaction from "Claude implements, you review" to "Claude thinks, you decide, Claude implements." Better results, fewer reverts.
Natural swap points
When to switch from navigator to driver (or take a break from Claude entirely):
- When you've been reviewing Claude's output without really reading it — that's drift, and you need to reset
- When Claude has made three decisions in a row that you'd have made differently — the framing has drifted
- When the problem requires understanding your specific context in a way Claude can't have — user research, product constraints, team dynamics
- When you realize you don't understand what Claude built well enough to maintain it
Ending the session well
Good pair programming sessions end with both partners knowing what was built and why. With Claude, that means an explicit close:
Before we finish: summarize what we built today, what decisions we made,
and what I need to know to work on this tomorrow without you.This is the session handoff note. It takes 30 seconds and means you can pick up the next day without reconstructing context from code.
When pair programming with Claude doesn't work
Some tasks don't benefit from the pair model:
- Exploratory work where you don't know what you're building yet — better to explore alone first
- Tasks requiring continuous judgment calls about product direction — Claude can't make those calls
- Work where you specifically need to learn — the driver role forces learning, the navigator role mostly just produces output
Pair programming setups and role prompts are in the Agent Prompt Playbook. $29.