Pair programming has always had a bit of a reputation problem.
It’s easy to look at two people working on the same task and see inefficiency. More coordination, more talking, less obvious forward progress. Even on teams that value it, there’s usually some quiet pressure to just go knock something out instead.
That tension has been around for a long time. What’s changed recently is how software actually gets from a person’s brain into a computer. Given this new paradigm, it’s important to evaluate the perceived gains that AI tools are making available to software teams.
I think anyone who believes AI has turned them into a 10x developer overnight needs to step back and reevaluate, because they might just be a 10x bullshitter. Pair programming is the perfect tool for this kind of evaluation, so make sure you’re bringing someone else along for the ride.
What’s Changed
Writing software feels different now than it did even a couple of years ago. With coding agents in the mix, a lot of the effort that used to slow you down has faded into the background. You can sketch out an idea, ask for a few variations, and end up with something that looks finished much sooner than you would have before.
When I’m working this way, I find myself moving through choices faster than I used to. I’m less likely to sit with a problem and explore a few directions before settling on one, partly because I don’t have to. Trying something out is cheap, and changing direction later feels manageable, so it’s easy to keep moving forward.
Most of the time, that works out fine, but it does change how aware I am of the moment where I’ve actually committed to a direction. The code shows up quickly, it looks reasonable, and I move on without spending much time questioning whether it really fits.
There used to be more natural friction there. Writing things out by hand forced a pause, even if it was brief. You had a bit more time to notice inconsistencies or second-guess an approach before it solidified into code. Now that pause is easy to skip, and the output you get back doesn’t give you much reason to stop. It’s usually clean, familiar, and internally consistent, which makes it easy to accept even when it doesn’t quite line up with the rest of the system.
I tend to notice those mismatches later, when I come back to extend something or try to connect it to other parts of the codebase.
That’s where pairing starts to feel less like overhead and more like a way to keep up with the pace.
Pairing to Keep Up the Pace
When you’re working with someone else, you explain what you’re doing as you go, and that explanation can surface assumptions you might not have examined otherwise. Questions come up naturally in that process. Why this approach? How does it connect to other parts of the system? What happens when something fails? None of these is especially deep on its own, but they add enough resistance to slow things down at the moment it matters.
Working with a coding agent has started to feel a bit like doing code review in real time. You’re constantly looking at something that was just produced and deciding whether it holds up. Alone, it’s easy to let things through that look fine at a glance. With two people, that filtering gets sharper. Someone catches a detail the other person glossed over or asks a question that changes how you look at the whole thing.
That becomes more noticeable when there’s a gap in experience. Pairing a more senior developer with someone earlier in their career has always had a mentoring aspect, but the presence of an agent adds a new angle. The suggestions coming back are often close enough to correct that it takes context to see where they fall short. Without that context, it’s easy to internalize patterns that aren’t quite right. Having someone there to point out those edges in the moment helps keep things grounded in how the system actually works.
Judgment Over Mechanics
There’s also a longer-term effect that’s easy to miss. When you pair program, it builds a shared understanding of the codebase that goes beyond any single task. You remember why certain decisions were made, or where something felt a little off at the time. That kind of context tends to matter later, especially when something isn’t behaving the way you expect.
At the pace that agents make possible, those moments seem to come up more often. You move quickly, cover more ground, and sometimes end up with pieces that don’t quite fit together. When that happens, having multiple people who have seen the code take shape makes it easier to reason about what went wrong and where to look.
On most projects, the difficulty isn’t in getting something to work at all. It’s in choosing the right thing to build and shaping it so that it holds up over time. That work depends on judgment more than mechanics. It shows up in tradeoffs, in consistency, and in small decisions that only make sense in the context of the system as a whole.
Those are the parts of the process that tend to benefit from conversation, and they’re also the parts that haven’t really been reduced by better tooling. If anything, they stand out more now, because so much of the surrounding work has become easier.
Why Pairing Still Matters
Pairing can feel slower while you’re doing it. There’s more discussion, and more time spent clarifying things that might otherwise stay implicit, so it’s easy to compare that moment-to-moment pace with working alone and assume you’re losing time. That comparison tends not to hold up over the length of a project. When you’re working at the pace that agents allow, most mistakes don’t slow you down right away. They show up later, once other work has started to build on top of them, and that makes its all the harder to back out of changes built on bad assumptions.
Those stops are expensive in a way that isn’t obvious when you’re moving quickly. When you pair program, it shifts some of that cost earlier by adding friction while decisions are being made. It can feel slower in the moment, but it often reduces the need to stop and unwind things later.
Framed that way, pairing is less about speed and more about when you want to pay for the decisions you’re making. With agents in the loop, it’s easy to defer that cost and keep moving. Pairing is one way to bring some of it forward, while the context is still fresh and easier to reason about, and lately that tradeoff has started to feel more worthwhile.