Pair programming was defined physically. Two people, one keyboard, one screen, close enough to point. Almost every description of the practice for twenty years described the seating.
Distributed work removed the seating. The practice should have gone with it, and largely it did not.
What actually transferred
Screen sharing with remote control turned out to be a workable substitute for one keyboard, and in one respect an improvement: handing over control is explicit and instant, whereas in person it involves a chair and some negotiation.
The bigger surprise was that remote pairing removed a social cost. Sitting beside someone for three hours is intense, and a lot of people quietly hated it while saying they found it valuable. A call that can be left is easier to enter.
Sessions got shorter. Frequency went up. Both are improvements, and neither was planned.
What did not transfer
Two things were genuinely lost.
Ambient awareness. In a room, you can tell when your pair is confused before they say so. Video gives you a fraction of that, and the fraction shrinks as the conversation gets technical and the camera gets ignored.
Casual initiation. Physical pairing began by rolling a chair over. Remote pairing requires a message, which means a decision, which means it happens less often for small things. The five-minute pair — historically the most valuable kind — is the biggest casualty.
Teams that pair well remotely have usually built an explicit replacement: a persistent open room, a norm that joining requires no invitation, or a short daily window where anyone can drop in.
The unexpected third participant
The other change is that code assistants have taken over part of the navigator’s role.
The traditional split was driver and navigator: one typing, one thinking ahead about structure and edge cases. A meaningful share of the navigator’s routine output — catching a missed case, suggesting the obvious refactor, remembering the API shape — is now produced by tooling.
This has not made pairing pointless. It has shifted it upward. The conversations that remain valuable are about whether the approach is right at all, which is precisely the part the tooling is worst at. Teams describe their pairing sessions as more architectural and less line-by-line than they were.
Where it still earns its cost
Pairing has always been expensive. Two people, one output.
The cases where it clearly pays are unchanged: onboarding someone into unfamiliar territory, working through a problem where nobody knows the shape of the solution, and touching code where a mistake is expensive to discover later.
The cases where it does not pay are also unchanged, and remote work made them easier to decline. That may be the practice’s real gain from the last few years — not a better tool, but a lower cost of saying not this one.
