Pair Programming in the AI Era

Pair programming and AI-augmented engineering.

I hear people saying that the practice of pair programming is now dead because no human can read the code at the generation speed.

I agree. With the fact that one can’t read and understand code so fast.

But let me offer you a reframing.

First. The practice of pair programming assumes two distinct roles: navigator and driver. While the driver holds the keyboard and types, the navigator is welcome to read. But mainly the value from the addition pair of eyes and the navigator’s intelligence comes from holding a broader frame.

What is a missing test? Which feature do we build next? Do we need this at all?

These are navigator’s challenges.

In the AI age? Can still be (and I claim must be) performed by the human. As I explored in Agile in the Age of AI, developers are becoming mini-Product Owners — deciding what code needs to be written, not writing it.

And now for the more important reframing. Imagine the old-times pair programming with two humans. One clicks to compile. A binary is produced. The tests are run. Feedback is generated.

Will the programmers bother to read the binary code?..

Likely not. So why don’t we look at the code that is AI-generated at the speed of light as the binary code and instead focus on high-level tests (like BDD level) that still can be discussed and paired on. This shift from routine to adaptive expertise — from executing known procedures to navigating novelty — is exactly where human pairs add value that AI alone cannot.