Thoughts and writing are my own. Proofreading done by AI.

While AI continues to change almost every aspect of how we do our jobs, we still seem to be in the dark with regard to what the future work process looks like. Good teams constantly adapt, new practices emerge, but there is no consensus on the best practices. Things are yet to settle, and we as a community are yet to define the new software development methodology.

I have previously expressed that many Agile practices are in fact confirmed by the use of AI, and still think it is true, with caveats. I didn’t start my career in Agile though, but with Rational Unified Process - a waterfall, to use a simplistic nickname. In a recent round of adapting our work process, I found myself thinking that in many ways going back to some of the old-school practices makes a lot of sense today. This is a topic for a different post, though.

But, this pushed me to re-read a few articles about the basics of Agile and XP in particular, as I wanted to separate the what (rituals, artifacts, etc.) from the why: what issues we were solving when the community was first introducing various Agile practices? And there it was. One practice I completely forgot about - Pair Programming.

–

Like every team out there, back in the day we experimented with pair programming too, but it has completely slipped from my memory since then. I’m not personally aware of any teams that actually retained the practice as the default way of working in the pre-AI era. (I don’t doubt that there are some, of course, just that I haven’t come across them recently.) I think there are many reasons: it defies the “flow” state, it felt awkward when a task needed some deep thinking or a lot of experimentation, some people were simply never comfortable with working shoulder-to-shoulder this way, not to mention that in many places it had to be defended as the managers would need to be convinced of its economics.

I am convinced however that the practice itself is sound. It is fun and engaging when it works, design quality goes up, and the pair learns a lot from each other.

You’re already seeing where I’m going with this. I said “pre-AI era” intentionally. Because I think we are all doing it now. I see a lot of our work with coding AI as pair programming. The recently evolved mantra about “the developer in the driving seat, and the AI doing the dirty coding work” doesn’t seem right. AI can make good product decisions, design the system, anticipate errors and failure scenarios, and more. The AI isn’t just a coder, and the relationship is more like the traditional navigator-driver pair. As a navigator I review the work of the driver (AI), albeit not line-by-line anymore. The navigator considers the strategic direction of the work, while the driver codes the implementation. And guess what? We also switch roles. I rarely, if ever, code now, but I’ll sometimes pause and ask the AI to work with me on the strategy, while I will be challenging its plan from an implementation perspective.

The flow is there, the quality goes up, and I am learning a ton. I would guess that model providers are learning a lot from our sessions too. Even if our relationship with model providers is complicated, I still hope they do learn from our AI sesisons, because it would mean that my contributions are worthwhile. All in all, pair programming by definition.

Why do I think this realization is important? Because we can probably do it better if we set our expectations right and know what we want to achieve from it, and also what to avoid.

First, there are some pitfalls to know of. Pair programming doesn’t work if the navigator withdraws. It’s easy to sit back and watch the AI work, but there is no learning there, and blindly signing off the results is irresponsible. (Having said that, fully autonomous coding is a valid thing I think, but a totally different beast that requires its own setup.) This can happen for many reasons, from being tired to being intimidated by the driver’s (the AI’s) “experience”, but none of them are good reasons to withdraw.

Then, there are best practices to know about. Feeling stuck? Set the objective clearly and explicitly, or redefine it better, or split the work into chunks and document them better. The task is too simple and well-understood? The driver can go alone and doesn’t need a navigator (give the AI full autonomy). Tired? Take regular breaks. OK, this one is obvious, but somehow we keep saying that working with AI is tiring, and yet 20 years ago we already recognized that working in pairs is tiring, and that breaks need to be more frequent - they are not only refreshing, but also create a calm space to think and generate more ideas.

I am certain that in practice the comparison is not as clear-cut, of course. But hopefully we can apply some past experience and invent a new, better methodology.

–

Over the past twenty years, pair programming slowly disappeared because it was awkward to do, defied the flow, and was hard to sell. With AI coding, it’s coming back to life: the flow is natural, the learning is faster, and the use of AI is encouraged. The other side of the coin is our attention span, so, guard it: keep your focus, take frequent breaks, stay engaged, and keep learning.