Developers reach for pair programming as the analogy for working with an assistant. The comparison is useful for a few days and then starts producing bad habits.
A human partner accumulates project context
The value of a long pairing relationship comes from shared history. A partner remembers the outage last spring and the reason a particular abstraction was rejected.
An assistant begins each session without that. It has whatever context the session supplies and no memory of why the codebase looks the way it does.
Developers who assume otherwise omit the background a partner would already have, and receive suggestions that are sound in general and wrong here.
Disagreement is the mechanism pairing depends on
Pairing works because a partner pushes back. Being asked to justify an approach either produces a better justification or reveals that there is not one.
Assistants generally accommodate. Stating a preference tends to produce agreement and an implementation of that preference, which feels productive and removes the check.
The habit worth carrying over is not asking for confirmation but asking for the strongest argument against the approach, which has to be requested explicitly.
The driver and navigator roles do not map
In pairing, one person types while the other watches for problems, and the roles rotate so both stay engaged with the whole task.
With an assistant the human is permanently the navigator, watching output rather than producing it, which is a mode that degrades attention over a long session.
Developers report reviewing less carefully as a session extends, which is a known property of monitoring tasks rather than a failure of discipline.
Knowledge transfer runs one way
A junior engineer pairing with a senior one absorbs judgment: which risks matter, when to stop, what to check before shipping.
An assistant transmits solutions without the reasoning that would let someone reach them independently, and nothing accumulates on the other side of the exchange.
Teams that noticed this began pairing juniors with people again for design work while using assistants for implementation, which separates the two purposes deliberately.
Responsibility never moves
Pairing distributes accountability across two engineers, both of whom answer for the change. That shared ownership shapes how carefully each of them works.
With an assistant the accountability remains entirely with the human, whatever the interaction felt like at the time.
Treating the session as collaboration rather than as authored work is the specific habit that leads to changes nobody can fully explain when they later fail.