The end of pair programming as we know it

Pair programming is one of those things that needs to be experienced to be fully appreciated.

For me, it has often been a tough sell for resistant developers, at least to begin with.

There is a natural tendency to retreat, to withdraw behind screens and headphones where we feel in control and don’t need to deal with the messiness of other humans.

It’s only once we move beyond that initial discomfort and experience the greater ease, joy and flow of pairing (acknowledging also its greater intensity, and the attendant energy management it requires) that it becomes something that happens organically, without so much need for encouragement or cajoling.

Executives can also feel resistant to pairing as a practice, as ‘rationally’ it seems as if it halves the amount of work that can be produced. The resistance is usually short-lived once they see that pairing doesn’t halve the output of their engineering teams; it tends to increase it, while at the same time, the number of defects and bugs decreases.

But with the promise and hype around AI reaching fever pitch and developers and their businesses driving for ever-greater efficiency gains through the technology, I fear this resistance will only get stronger.

The common developer instinct to retreat into their own bubble and disconnect from the wider team, as well as business focus on increasing individual developer throughput, may be amplified by the siren song of vibe-coding and AI codegen.

This may be the end of pair programming as we know it.

But hope is not lost.