Not always in pairs

A few years ago I spent day after day in the same call with a colleague. One shared screen, two pairs of eyes, one cursor that switched keyboards every so many minutes. Pair programming, the way it was supposed to be done at the time.

In theory, the best of both worlds. In practice: empty in the evening, restless at night, and the feeling that I was getting better at holding focus next to someone than at actually thinking.

Pairing has its place

Onboarding a new colleague. A corner of the code nobody else knows yet. A knot that genuinely gets cut faster with two heads. That’s where pairing works. A few hours a week, with something concrete as the goal.

What I lived through was something different. Pairing as the default. Eight hours a day, five days a week, two people on one keyboard. No room to try something you’d later describe as “what a detour, but now I get it.” No silence to let an idea ripen. Continuously talking about code that still has to be written.

Constant pairing feels productive. Until you notice you’re nobody without someone next to you.

The quiet cost

You don’t feel it right away. The work moves forward, your colleague is mostly pleasant, and saying that pairing wears you out sounds weak. So you keep quiet. And you carry on.

Until one Wednesday evening you can’t pick up what you wanted to do on Friday. Until you notice you no longer form an opinion without first checking how the other person reacts. Until deliveries land, but you no longer know whether the thinking was yours, or the pair’s.

That’s where creativity slows down. And thinking something up yourself — really yourself — becomes a muscle you no longer use.

A navigator that doesn’t run out

What eventually pulled me out of that pattern was being able to choose work where pairing was no longer a reflex. No anti-pairing posturing — simply: pairing where it adds something, and the rest of the time, thinking.

What surprised me after that: a large part of what a constant pair-buddy offers, you can now get from a good model. A second pair of eyes on a function. A quick explanation of a framework you don’t see every day. A line of reasoning written out, to check whether it holds. Not to replace people — to fill the navigator’s seat when no human is needed for it.

It’s not an alternative to an experienced colleague at the right moment. It’s a way out of “we always do everything together.”

What that means for clients

No work that costs more because two heads have to be paid for one keyboard. No team that burns itself out because the working model demands it. Pairing where it genuinely makes a difference — onboarding, a sensitive piece of code, a decision that won’t get cut with one pair of eyes — and the rest of the time, people each doing what they’re sharpest at, with an AI navigator within reach.

AI as acceleration, not as decoration. People where it matters, models where that’s more efficient.