Pairing in 2026

Pair programming goes back to the 50s and 60s (back when dinosaurs roamed the Earth), two programmers hunched over consoles together, thinking aloud and implementing the code together. It stayed unnamed for decades until it was formally named for the first time by Larry Constantine in 1995. It became popularised by the legendary Kent Beck, who introduced it as one of the practices in XP (extreme programming).

A lot of XP principles appear counterproductive at first, pairing included, and have had a lot of pushback for the more than two decades since they were first published. There's a lot of reasons teams or management may push back, one being: why pay two engineers to do one person's job, especially when you can use AI to output code fast?

Hold up.

Outputting code is nice and all but how do you know what code to even put out?

Requirements are everything, and you cannot know them through AI. AI doesn't understand your business or your customers, although it can certainly pretend that it can! I cannot count how many times I've been using AI to assist me and encountered tough, obscure edge cases, or arrived at a crossroads where I had to decide what the business wants to do in a given situation. If I make the wrong decision upstream, the business has to deal with a lot of downstream effects — one example being increased support workload — and I'd personally prefer to stay in the Head of Customer Success's good books.

The new alerts experience for Vouchsafe took around two months to ship. I'm a heavy user of AI, and the biggest constraint I had was pausing very frequently to consider the consequences of a decision: a new database schema change, architecting and deploying the cloud infrastructure to support it, validating assumptions that turned out to be untenable, design decisions, how to position the product to appeal to compliance officers. A big chunk of my time went into deliberation, and in hindsight I admit that my feedback loop was not short enough. Despite async communication channels and working under the supervision of the CTO, I took far longer than I should have pushing this into production.

My point here is not that speed would have been better, but that the earlier I put it in production, or something at least similar to it, the quicker I could have gotten feedback. One of the main ways I could have shortened that feedback loop significantly was to pair with colleagues. A mob programming session with the CTO and design engineer, for example, with me driving the AI, would have significantly cut down development time and allowed us all to validate our pre-existing assumptions. All the great practices are really just ways to create a feedback loop, whether TDD, talking to the customer, or pairing, but today we're talking about pairing, so let me not get ahead of myself and save the others for another time.

So, pairing…

One of the clearest examples of where the benefits of pairing really shone through was deploying a machine learning model to improve our photo ID and supporting document detection. We needed to get it deployed and the logic written into the app for all 8 kinds of photo ID we support as well as supporting documents. One engineer had a much deeper understanding of the domain and edge cases since they had built the system, whilst the other engineer (ME!!!) was proficient in implementing things very quickly with AI.

Had I done that alone, there would have been some edge cases I would have missed. Since we were under pressure to deploy this change and being relatively new to the company, I did not understand all the implications of changing some areas of our codebase. I was able to use AI to sketch a rough implementation, once my colleague had scoped out the requirements and written down the implications of our changes, and we gained feedback on our solution very quickly. We refined the rough implementation and deployed it that afternoon. Considering the success of that pairing session, we were eager to pair more in the future.

From our future pairing sessions, we gained immense benefits. Speaking for myself, I gained hard-won domain context, was forced to communicate clearly in the moment and explain my solutions, developed a much stronger bond with my colleagues, and got feedback on my ideas and potential solutions very quickly. I was also able to transfer technical knowledge and introduce new architectures and patterns and gain feedback on them too.

Another benefit I've gained, which I've never heard pairing advocates mention, is that it helped mitigate the effects of AI-fatigue. AI-fatigue is like how you feel after doomscrolling for many hours, quite overstimulated. Pairing mitigated the effects of AI-fatigue in several ways, and dare I say, I've found it to be the only effective solution to this issue that has plagued so many engineers recently in the field, experienced ones included. One way it reversed AI-fatigue was that I was forced to explain my rationale behind everything, and was held accountable for all my ideas; therefore my brain was constantly active and engaged. It was still exhausting but the good kind, the 'I ran for 2 hours and my body is tired but my soul is alive' kind. And my soul did feel truly alive after doing it. There's something really fulfilling about collaborating with other human beings in real-time compared to playing a game of ping-pong over Slack.

Pairing can be cognitively exhausting, which isn't a bad thing in itself, just something to expect. So much is being learnt and a lot of high-quality work is being done, so it'll be tough to do for long stretches, especially at the start. It's also a bit awkward at the start and takes practice to get into properly. Some respected engineers also believe it is not appropriate for every situation and should be limited to scenarios where the problem at hand is difficult and full of edge cases.

These objections are reasonable and noted, though I think pairing should be tried out a lot more regardless, even in situations where the issue is not overwhelmingly difficult, since the main gain of pairing is feedback. Teams that have been avoiding it should experiment with dropping their existing assumptions about what works and what doesn't, try it out, and measure the impact over a long period. Crucially, the benefits may not be obvious in the short term, but if a few months down the line, you feel you can make changes quickly and with confidence, then maybe it's a sign it's a practice worth keeping.

To be frank, pairing is only part of the solution. It goes hand-in-hand with other good practices like test-driving and architecting the app so that change is cheap. Businesses, especially startups, are forced to respond to changing requirements: customer feedback shifts, policies in your field are updated and the law changes. In order to quickly respond to these changes, you need to have the confidence that your changes won’t break the app, confidence that good tests give you, which depends on a well-architected app, which is difficult to get right alone. The cognitive load of all of that can be pretty tough for a single engineer to handle. So why not share it, and make that work feel alive again?