A little less conversation....

How pair programming finally became the default mode for software development, and what happens next.

There’s a seductive idea gaining traction in software development: that AI will eventually replace the engineer. Not augment, not assist. Replace. The reasoning is straightforward. If a machine can generate code, review it, test it, and deploy it, then the human in the loop is a transitional cost, not a permanent fixture.

While the behaviour of software engineers is changing in response to better tooling, there’s little evidence that imminent replacement is underway. What we have been seeing is something we do have evidence for, decades of it, which is that software improves through conversation.

It’s now or never

Pair programming put two developers at one workstation, thinking aloud together. Laurie Williams’ research demonstrated that pairs produced fewer defects and better designs, even when the practice looked wasteful by any measure of individual output. The secret wasn’t doubling the number of engineers solving a problem. It was the conversation: explaining an approach forces clarity, being challenged before an assumption hardens into architecture solves potential problems cheaply, before they manifest as expensive bugs or outages.

Pair programming was championed by XP, but even the organisations that moved toward XP or later agile practices, tended to file pair programming under “nice idea, too expensive.” Two salaries for one keyboard.

So pair programming remained a niche practice, or became refinement, or distillation. Conversations in advance of the work instead of conversations during it. The rest of the industry optimised for individual throughput and absorbed the rework as a cost of doing business.

Surrender

Then copilots arrived. GitHub Copilot, Cursor, Claude Code, Amazon Q. Organisations adopted them with an enthusiasm that would have been unrecognisable to anyone who ever tried to get pair programming funded.

The adoption wasn’t driven by a sudden conversion to the benefits of pair programming. The impetus was the AI arms race. Every competitor was doing it. Every conference was talking about it. Every engineer wanted to get their hands on the tools. The cost was trivial; a copilot subscription is less than a rounding error on an engineer’s salary. Even the more sophisticated tools carry a cost profile well below a second engineering salary.

What we’re seeing now is the beginning of a new iteration of pair programming. The most effective adopters of AI explain what they’re trying to build and interrogate the response. They prompt the copilot to challenge, suggest alternatives, and force them to improve their approach based on feedback.

Ask me

Now, we see organisations that lagged on pair programming rushing ahead into the next stage. Conversations have gone from “we won’t pay for two humans to do this” to “what if we don’t need the human at all?”

Both positions ignore the same evidence.

The conversation that makes software better requires someone who knows what problem is worth solving. Someone who brings taste, context, an understanding of the user that isn’t derived from a training set. The human in the pair isn’t there to type. She’s there because she has organisational context and can represent the views of users, customers, and the history of the codebase. The act of explaining that to a thinking partner, human or machine, is how that idea gets refined into something that works.

Remove the human, and you still have a system that can generate code. Rapidly, fluently, at scale. You also have a system with no one to tell it whether the code is worth generating. Speed is table stakes. Knowing what’s worth building is where competitive difference lives.

The risk isn’t that AI gets too capable. The risk is that the organisation optimises the human out of the conversation before it understands what she was contributing to it.

Suspicious minds

Pair programming was rejected because it was “too expensive.” AI pair programming is cheap by comparison. AI-alone programming would be cheaper still. The price of the conversation has always been driven by the cost of the second participant. The value of the conversation is driven by the person who knows what’s worth building. A little less conversation could end up costing your organisation a lot.