Pair programming, in its original sense, was a practice between two humans: one driving, one navigating, both engaged with the same problem at the same time. The driver typed. The navigator watched, asked questions, caught mistakes, thought about what came next. They switched roles. The discipline was that neither could check out — disengagement defeated the point.
The practice translates better to working with an agent than people usually expect, and the translation reveals what is actually at stake.
The risk
Working with a stronger pair partner has always carried a specific risk: you stop thinking. The other person is faster, more confident, more likely to know the answer. The path of least resistance is to type what they say and stop forming your own opinions. The result is short-term productivity and long-term skill atrophy. You finish the task. You also finish the task without learning anything, and the next time you face a similar problem alone, you discover that you cannot.
This was already a known dynamic with junior-senior pairing. With agents, the asymmetry is sharper. The agent is faster than any pair partner you have worked with. It is more confident, by virtue of being a system that does not hedge. It will produce a full answer to almost any question you ask. The temptation to type what it says and move on is correspondingly stronger.
The risk is not that the agent will produce bad code. The risk is that you will accept good code without understanding it, and that this becomes the default, and that one year in you are shipping work whose internals you cannot explain.
The practice of pair programming was, in part, a defense against exactly this dynamic. The defense translates.
Driver and navigator
In a human pair, the driver types and the navigator watches. The roles are deliberate. The navigator's job is to ask questions, hold the larger picture, catch the mistake the driver is too close to see.
In a session with an agent, the agent is the driver. It is the one producing code. You are the navigator. This is the right framing because it puts the cognitive work in the right place: the navigator is not idle. The navigator is the one thinking about whether the direction is correct, whether the change fits the system, whether the test actually tests the thing.
The failure mode is to be a driver without a navigator. You sit in the seat the agent should have, asking it to type out what you tell it to. This makes you the bottleneck on what you already know how to do, while the agent produces less interesting output than it could. Worse, it leaves no one in the navigator seat. The car is moving and nobody is looking at the road.
The better arrangement is to let the agent drive — let it propose, generate, sketch — while you hold the navigator's responsibilities. Where are we going? Does this turn make sense? Are we still solving the problem we started with? The agent will not ask these questions. They are yours.
Asking why
A navigator's most valuable habit is asking why. Why are we using this library? Why is this function in this file? Why does the test check that and not the other thing? The questions are not adversarial. They are how the navigator stays oriented.
With an agent, this habit is preserved by asking the agent its reasoning before accepting its output. Not "do this" and then read the diff; "what would you do here, and why?" and then read the answer. The why is what reveals whether the agent has understood the problem or pattern-matched to a superficial similarity.
This adds friction. That is the point. The friction is the discipline. An agent that has to explain its choices is an agent whose choices are easier to evaluate. A you who is asking why is a you who is staying engaged.
If you stop asking why, you stop being the navigator. The session continues, but the work is happening without supervision.
Reading the diff before accepting it
The single most important habit, and the one most often skipped: reading the diff before accepting it.
This sounds obvious. In practice, the rhythm of working with an agent makes it easy to skip. The agent produces a change. You glance at it. It looks right. You accept it. The next prompt is already forming. The diff lives in the codebase now, and you have not actually understood what it did.
Multiply this by ten interactions a day and you are shipping a meaningful fraction of your output without having read it. The atrophy is silent at first. The bugs that surface from this are bugs you cannot diagnose, because you do not have the model in your head of how the code is supposed to work.
The fix is the boring one: read the diff. Every time. Even when you trust the agent. Especially when you trust the agent. If the diff is too large to read, the right move is to ask for a smaller diff, not to accept the large one unread.
The reading is not just verification. It is the part of the session where you build the mental model. Skipping it gives up the learning. The learning is most of the point.
The role you can never give up
There is one job the agent cannot do for you, and that is hold the original intent.
You started a session with a problem to solve. Three exchanges in, the conversation has wandered. The agent has proposed a refactor, suggested a related improvement, identified an adjacent bug. Each suggestion is reasonable in isolation. Together, they have moved you ten degrees off course. The PR you end up with solves a different problem from the one you started with, and the original problem is still there.
The navigator's last job is to keep the destination in view. The agent will optimize the local terrain. You hold the map. If the suggestions are pulling away from the goal, you bring them back. If a tangent is more interesting than the original task, you make that a deliberate decision rather than a drift.
This is the role that does not delegate. Whatever else the agent takes off your plate, the holding-of-intent stays. A pair programming session where neither party remembers the goal is a session that produces motion without progress.
Staying sharp
The practices add up to something simple: stay engaged. Read the diff. Ask why. Hold the goal. Switch off when you notice yourself accepting work you do not understand.
These are the same practices that made human pair programming valuable. They were never about typing the right thing. They were about the discipline of two minds on the same problem, neither one allowed to coast. With an agent, you are one of the two minds, and the other one will never get tired. The risk is that you will, and that you will start coasting without noticing.
The hedge against this is the practice. Pair programming was always a discipline. With an agent in the other seat, it is the only discipline that keeps you in shape.
Top comments (0)