Pair programming with a colleague and working through a task with a coding agent produce different code, even when the task and the person are the same. It is worth naming why, because teams often assume the two are interchangeable and adjust neither their expectations nor their process for the difference.
A human pair pushes back
A colleague will say "I don't think that's right" before you finish the sentence, based on a hunch built from experience with this exact codebase. A model, by default, tends to run with the direction it is given and produce something plausible in that direction, correct or not. The friction that catches bad ideas early in human pairing has to be built deliberately into a session with a model — asking it to critique its own approach before writing code, for instance, rather than assuming it will volunteer doubt.
A human pair gets tired; a model doesn't, which is its own risk
Long human pairing sessions naturally taper off as both people's attention drops, which is itself a signal to take a break. A long session with a model produces output at a constant rate regardless of whether the underlying reasoning is still sound, so the natural braking mechanism is missing. We now time-box sessions explicitly rather than relying on either party to notice fatigue, because only one of them can.
What each is actually good for
- Human pairing — genuinely novel problems, architecture decisions, anything where the value is in the disagreement itself.
- Model pairing — well-specified, bounded tasks where the spec does most of the thinking and the model's job is fast, tireless execution against it.
- Neither, alone — a task with an unclear specification. Pairing of any kind does not fix an unclear brief, it just produces the wrong thing faster.
The value of a human pair is often the argument, not the code. The value of a model pair is speed once the argument is already settled.
Where teams get this backwards
Using a model for the architecture conversation and a colleague for repetitive scaffolding is the wrong way round for most tasks, and yet it is the default when whoever is free gets assigned to whichever kind of work is in front of them, rather than matching the tool to the nature of the task.
The habit worth keeping
Decide before starting a task which kind of pairing it calls for, based on whether the hard part is deciding or executing. It is a small decision and it changes which mistakes you are likely to make.