Pair-Programming Patterns — Claude Code

The workflow#

Pick a role for the session: driver (you type, Claude observes and suggests), navigator (Claude types, you direct and review), or ping-pong (you trade off at natural seams). Hold the role consistently for a chapter of work. Switch roles at chapter boundaries, not mid-flow. Talk through what you’re doing — out loud or in chat — so the model has the context to be useful and so you stay engaged with the code rather than spectating.

Pair programming with a human and pair programming with Claude Code share the same underlying mechanics: two agents, one keyboard, one shared model of the work. The difference is that one agent is excellent at typing fast and pattern-matching to known shapes, and the other agent is excellent at judgment, taste, and knowing when something feels wrong. The patterns below let you play to both strengths instead of letting Claude become an over-eager autocomplete or letting yourself become a passive observer.

When to reach for it#

Pair-programming patterns are the right frame whenever you want to stay in the loop on the code, not just receive a finished diff:

Learning a new part of the codebase. Pairing makes you do the navigating, which forces you to actually understand the structure.
Building muscle memory in a new language or framework. You type, Claude suggests; you internalize patterns through the typing.
Working on the kind of code you’ll need to maintain long-term. Code you wrote with engagement, you remember. Code you skimmed-and-accepted, you don’t.
Mentoring or pairing with a less experienced teammate. The patterns generalize — Claude becomes the silent third pair, suggesting improvements without slowing the conversation.
Tasks where staying engaged matters more than throughput. Sensitive business logic, security-adjacent code, anything where “I trust this because I wrote every line” has real value.

Don’t reach for pair-programming patterns when:

Throughput matters more than engagement. Bulk renames, mechanical refactors, code you’ll never read again. Let Claude drive autonomously; review the diff at the end.
You’re genuinely just out of energy. Pairing requires attention. If you don’t have it, conversation-driven development with Claude doing more of the work is fine; pair patterns are an honest commitment to staying in the loop.

Step-by-step#

1. Pick a role for the session#

Three primary roles. Pick one and hold it.

Driver (you type, Claude observes). You write the code. Claude reads what you write in the diff and suggests improvements, catches bugs, proposes the next step. Use when you want to internalize the code by writing it.
Navigator (Claude types, you direct). Claude writes the code. You give intent, review every diff, redirect with single sentences. Use when typing is the bottleneck or when Claude knows the codebase better than you do at the moment.
Ping-pong (you trade off). You write a failing test; Claude implements. Claude proposes the next test; you accept or rewrite. You refactor; Claude reviews. Trade at every natural seam. Use when the task has clear handoff points.

The single most-common mistake is no role — drifting between modes without intent, ending up with Claude doing 90% of the work while you nominally drive. Pick a role; commit to it.

2. State the role explicitly#

Tell Claude which role you’re playing. Not because it dramatically changes Claude’s behavior — it’s not a built-in mode — but because naming it changes your own behavior. If you’ve said “I’m driving this session, you observe and suggest,” you’re more likely to actually type rather than ask for proposals.

A typical opener:

Pairing on the auth-flow refactor. I’m driving; you observe and call out anything I miss. Don’t propose unsolicited changes — wait for me to ask, or speak up only for correctness issues. We’ll switch to ping-pong if we hit a multi-file change.

3. Establish the shared context#

Like with any pair session, you need a shared mental model of where you are and what the goal is. The minimum:

What you’re doing. One sentence of intent.
Where you’re starting. Which files, which test, which branch.
What “done” looks like. Acceptance criteria, even informal.

Skipping this step in human pairing produces awkward “wait, what are we actually doing” moments 20 minutes in. Skipping it with Claude produces the same problem with worse symptoms — the model rationalizes a goal from the available context, and the goal it picks may not be yours.

4. As driver: type, then ask#

In driver mode, the rhythm is type, then ask, not ask, then accept.

Write the function signature.
Write the test.
Implement.
Then ask Claude: “Anything I missed? Edge cases? Better names?”

The order matters. If you ask first, you get a proposal you’re inclined to accept, and you’ve become navigator without realizing it. If you type first, you get a proposal that’s a check on what you wrote — far more useful, far less passive.

5. As navigator: state intent in chunks#

In navigator mode, the temptation is to delegate the whole task in one prompt. Resist it. Navigator-style pairing works because the navigator chunks the work into reviewable steps.

“Add a refresh-token field to the AuthContext type.”
“Update the login flow to populate it on initial authentication.”
“Update the logout flow to clear it.”

Three steps, three diffs, three opportunities to redirect. Not one prompt, one giant diff, one chance to catch issues.

6. As ping-pong partner: trade at seams#

The natural seams for ping-pong with Claude are:

Test → implementation. You write the test; Claude implements; you refactor.
Spec → code. You write the docstring or type signature; Claude writes the body.
Code → tests. You write the body; Claude writes the tests against it.
Diff → review. Either of you writes a diff; the other reviews critically.

The handoff is explicit. “Your turn.” Without the explicit handoff, ping-pong degrades into either driver mode or navigator mode by default.

7. Talk through what you’re doing#

Pair programmers talk. Out loud, on a call, in chat — somehow. The talking serves two functions:

It keeps the partner oriented. Claude reads what you type but can’t read your screen scroll, your editor state, what you’re thinking about looking up. Narration fills that gap.
It keeps you honest about your own reasoning. “I’m doing it this way because…” forces you to have a reason, which is what catches the half-formed assumption before it ships.

In practice, this often looks like one-line comments in the chat as you work: “Going to extract this into a helper because we’ll need it for the logout case too.” or “Putting the validation here for now; might move it later if it gets reused.”

8. Switch roles at chapter boundaries#

When a chapter of work ends — commit, test green, feature done — that’s the natural moment to switch roles for the next chapter, if you want to. Mid-chapter role switching is disorienting and usually leaves you in a worse role than you started in. Chapter-boundary switching is clean: new context, new role, fresh focus.

A long pair session might cycle: drive the test-writing chapter, navigate the implementation chapter, ping-pong the refactor chapter. Each chapter’s role is suited to the kind of work in it.

Anti-patterns#

The shapes that don’t work:

No declared role. You drift between modes, lose track of who’s responsible for what, end up surprised that you accepted 200 lines of code you don’t quite understand. Always pick a role.
Driver-in-name-only. You’re “driving” but actually asking Claude for the next step every 30 seconds. That’s navigating with extra friction. Either really drive — type the code — or own the navigator role honestly.
Navigator who delegates the whole task. “Implement this feature with tests and edge cases” is not navigating, it’s prompt-and-hope. Navigating means chunking, reviewing each chunk, redirecting in flight.
Ping-pong that becomes one-sided. You hand off, Claude works, you accept, Claude works again. That’s not ping-pong; that’s Claude driving with extra steps. The trade has to be real — your turns produce code, not just approvals.
Skipping the role-statement opener. Without naming the role, you default to whichever role is easier, which is usually “passive recipient of Claude’s output.” Saying the role out loud is what makes the role real.
No talking through what you’re doing. Silent pairing with a human is bad; silent pairing with Claude is worse because the model has even less ambient context to work with. Narrate.
Switching roles mid-chapter. “Actually, you take over for a bit.” Disorienting. The partner now has to reload context that the previous role-holder had. Switch at boundaries.
Pair-programming on truly mechanical work. Renaming a variable across 80 files doesn’t need pair patterns; it needs Claude in navigator mode running flat-out while you review the diff at the end. Save the pair patterns for work where engagement matters.
Pair-programming when you’re too tired to engage. Pair patterns require you to bring something — typing, judgment, narration. If you don’t have it, you’ll end up as the worst kind of navigator (passive) without realizing it. Better to acknowledge the energy gap and let Claude do more, with you reviewing at coarser grain.
Forgetting to actually commit. Same problem as conversation-driven development: long sessions without save points. Pair sessions are not exempt; commit when green.

Evaluation#

How do you know the pair-programming workflow is working?

You can describe what you changed and why, without looking at the diff. Real engagement means real retention. If you can’t, you were spectating.
Claude’s suggestions surface things you’d have missed. Edge cases, sibling bugs, better names, missed tests. If Claude’s contributions are all stylistic nudges, you’re either not asking the right questions or you’re overqualified for the task and should be using a different workflow.
Your suggestions surface things Claude would have missed. Business context, naming conventions, architectural fit, “this is wrong but I can’t yet say why.” If you’re only accepting, you’re not pairing — you’re reviewing autocomplete.
The role stays stable within chapters. If you find yourself drifting from driver to navigator three times in twenty minutes, you didn’t really commit to a role.
Sessions feel collaborative, not transactional. “We’re building this together” rather than “I asked, the tool delivered.” The phenomenology matters because it tracks whether you’re staying engaged.
Code you wrote with pair patterns, you remember and understand a week later. This is the long-term test. If pair sessions and prompt-and-hope sessions produce equally-amnesiac results, the pair patterns aren’t doing their job.
You’re not exhausted at the end of a long session. Real pair programming is energizing if the role suits the work. If it’s draining, you’re probably in the wrong role for the task — try switching for the next chapter.

Pair patterns with explicit role. You stay engaged. Claude’s contributions check your work; your contributions check Claude’s. Code you wrote, you remember. Slower-feeling than autonomous Claude; more durable understanding.

Drifting collaboration. No declared role, no narration, no rhythm. You accept most of Claude’s output because the path of least resistance is acceptance. Faster-feeling; produces code you can’t fully describe a week later. Fragile maintenance position.

The pair-mode opener I use most often

Roughly: “Pairing with you on [task]. I’ll drive — I want to internalize this part of the code. Observe and call out anything I miss: missed edge cases, off-by-ones, things that don’t match repo conventions. Don’t propose stylistic changes unless I ask. We’ll switch to ping-pong when we hit the testing chapter, and you can navigate the refactor chapter at the end if we get there.” That single opener sets the role for each chapter and pre-commits me to mode switches at the right moments, so I’m not deciding-in-flow whether to keep typing or hand off.