Pair programming in an agentic world

I have been wondering whether coding agents are making software development a more solitary activity.

The pattern I am starting to notice is that human pairing remains useful when starting a project: discussing the problem, challenging assumptions, deciding how the pieces should fit together. Once there is enough direction, it becomes easier to work independently with agents. The conversation continues, but increasingly it is a conversation with software rather than another developer.

What troubles me about that possibility is how much happened during pairing that nobody explicitly asked for.

Imagine asking a colleague to help with a failing test. During the investigation, they explain an unusual constraint, notice an assumption you missed, and learn something about a component they have not touched before. You wanted a test fixed. You also exchanged knowledge and developed a shared understanding.

It was also a chance to talk with a teammate. Some of that conversation might have had nothing to do with the test. You got to know each other a little better while working through something together.

An agent might help fix the same test without involving the colleague. The immediate task has been completed. The team has not necessarily gained another person who understands it, and that occasion to spend time together has disappeared too.

I am interested in what happens when the immediate reason to involve a colleague disappears while the other reasons remain.

Following the work or receiving the result

Driver/navigator and ping-pong pairing describe how people participate. Either can serve different purposes: implementation help, continuous review, learning unfamiliar code, or questioning an approach. Those purposes also bring people together outside pair programming, when we review a change or talk through a design.

I can give an agent an implementation task and let it work through the code and tests. I do not have to guide every step.

I can stay close: discuss an approach, inspect a small change, question it, and decide what to do next. Calling that pairing seems reasonable enough. Or I can describe the result I need, let the agent work, and return to inspect what it produced. That is delegation. In the first case I follow the decisions as they happen; in the second I need to reconstruct enough of the reasoning to judge the result.

I can work either way on my own, but I can also bring a teammate into the session. The agent can handle the implementation while we discuss the approach, question its changes, and explain things to each other. We still have reasons to work together even when neither of us is typing the code. But staying together through the whole implementation may be a less valuable use of our time than coming back together when there is something to discuss.

Debugging without the conversation

I can take a failing test or an unexpected result to an agent and work through it without asking a colleague for help. If we find the solution, I can move on. A problem that might once have prompted "can you look at this with me?" never becomes a conversation with the team.

In a shared investigation, a colleague might explain a part of the system I do not know, question an assumption, or learn something from how I approach the problem. We get to see which clues matter and why an explanation turns out to be wrong.

I can share the fix and write down how I found it, so teammates can follow the investigation later. They can question an assumption or point out something I missed. But if I only post the change and move on, I may never find out what they understood or where they got stuck.

Bouncing ideas off each other

One of the things I want from pairing is someone to think with while an idea is still taking shape. I suggest an approach, my teammate changes part of it, and I build on their suggestion. Neither of us needs to arrive with a finished proposal. The back-and-forth helps us work out what we mean.

That can start with a small implementation question: where should this behaviour go? We try it in one place, look at the data it needs, and realise that we are making another component responsible for something it should not own. The conversation moves between the code in front of us and the structure around it. Writing a little code gives us something to react to and can change the direction of the discussion.

Then there is the context beyond the code. A teammate might know that another team depends on this behaviour, that two integrations need to evolve independently, or that an operational constraint rules out an otherwise appealing approach. Those details can change which implementation makes sense. I may not have known to include them in the question I started with.

I can bounce ideas off an agent too, ask it to explore alternatives, and try an implementation. With a teammate involved, we can let the agent do that work while we discuss what fits, what needs to change, and what else we need to know. That is a pairing session I can see a reason to keep: we are still working out the approach together as the code takes shape.

A partner who does not push back enough

An agent can be too willing to develop my idea without adequately questioning it.

Consider a proposal to split a service into three smaller services. An agent might design the boundaries, generate the interfaces, and work through the migration competently while leaving the most important question underexamined: should we split it at all?

Once I commit to that direction, every difficulty can become another task for the agent. I get absorbed in making the split work and stop asking whether it is worth doing. The agent keeps helping, and I can go further down the rabbit hole while feeling that I am making progress.

A teammate might stop me and ask what problem we are actually solving, or whether we could solve it with a smaller change. That can be frustrating when I am caught up in an idea, but it gives me a chance to step back. Without someone questioning the direction, I can spend a lot of time solving problems that the original decision created.

Reviewing what the agent produced

Code review can mean finding mistakes in a diff, deciding whether a change is acceptable, or learning how the system is evolving. Automating one of those activities still leaves the others to consider.

Some people now question whether code still needs to be reviewed by a person at all. That makes me ask what we are using code reviews for in the first place, and which of those purposes an agent can fulfil.

Formatting and mechanically enforceable conventions should already be checked before a reviewer arrives. Agents can attempt a broader first pass, although their findings still need validation. Where that helps, I would use the time to examine questions such as whether the behaviour belongs in this component, whether it changes a contract another team depends on, and whether the tests check the requirement or merely repeat the implementation's interpretation of it.

Even a small change can need careful review. A one-line change to an authorisation condition can matter more than a substantial refactor. "Focus on the big picture" is poor advice if it encourages us to overlook a small decision with large consequences.

We might spend more time agreeing acceptance criteria, examining risky changes, or questioning the evidence that the code works. Removing an approval step still leaves the question of who else understands the change.

What the mentor no longer sees

An agent is useful when I want to understand what the code does. I can ask it to walk through an unfamiliar component, explain an API, or help me understand a test, without waiting for someone to be available.

How we got to that code is a different question. A teammate might remember what we tried before, why we abandoned it, or which constraint led to an awkward compromise. An agent can use that history when it is recorded. When it is not, a convincing explanation of the code may miss the reason we wrote it that way. That context helps someone learn when to keep a decision and when to revisit it.

Teaching is part of the learning too. When I explain a decision, I have to make the reasoning clear. The other person's questions may expose an assumption I have stopped noticing. If those questions go only to an agent, we lose that exchange, and I may never see where a teammate needs help.

Shared understanding needs somewhere to happen

I can work through a problem with agents and show the team the finished change. They see the result, but have missed the conversation that led to it.

Asking an agent can feel easier than interrupting a teammate. We could use the time we save to talk through a design or help someone with unfamiliar code. But the small conversations that happened while fixing a bug are easy to lose, because we never planned them in the first place. Those were also chances to notice where someone was struggling or understood the problem differently.

I may be able to make a change on my own, but my teammates still need to understand it. The work can move forward without that conversation, so it is easy to skip. Talking through the change gives them a chance to understand why I made it and question the decisions behind it.

A partner that never needs a break

Pairing with a person requires accommodating another person's pace. Someone needs coffee, wants time to think, or has reached the point where they are no longer contributing much. The session has interruptions and an eventual end.

With an agent, that negotiation largely disappears. I can ask another question, explore another approach, or hand over another change without worrying that I am exhausting someone's patience. That availability is part of the appeal. It can also make work feel permanently available: the fact that another iteration is possible starts to feel like a reason to do it.

Availability and excessive agreement can reinforce each other. A partner that readily follows my direction and never needs to stop makes it easy to sustain an approach that deserved questioning, or simply continue beyond the point where I am thinking clearly. An independently working agent could equally be what allows me to step away.

Whether that gives me more freedom also depends on what the team expects. If every task finished sooner becomes a reason to assign another, stepping away is harder than simply deciding I need a break.

An agent that never needs a break does not make me a developer who never needs one.

What are we pairing for now?

Before dropping a human pairing session, I would ask what the other person's involvement was supposed to achieve. If the purpose was to resolve a routine implementation problem, perhaps the agent has met that need. If it was to challenge a decision, help someone grow, or leave more people understanding the system, finishing the code may not meet that need.

Before giving the agent another task, I would ask myself whether I should keep working, talk it through with someone, or take a break.

We need to decide how we want software development to move forward. Agents may help us get more done, but I worry about a future where we work more alone and find it harder to stop. Greater productivity would lose some of its appeal if it also left us more isolated and more likely to burn out.