You can't pair-program with an AI. That's the whole point.

My favorite pair-programming partner is a person named Sara. My most-used pair-programming partner is Claude.

The two experiences have almost nothing in common, and the AI industry keeps insisting they should.

I want to be careful here. The marketing of AI coding tools has converged on the framing "your AI pair programmer". GitHub uses the phrase. Cursor uses it. Replit uses it. Half the SaaS pitch decks I've seen in 2026 contain the phrase. It rolls off the tongue. It's also subtly wrong, and the wrongness has real consequences.

Pair programming with a human and "pairing" with an AI are different activities. They produce different code. They develop different skills. They feel different. They're good at different things. Pretending they're the same — even casually, in a marketing tagline — leads us to ask the wrong questions and optimize the wrong metrics.

What I learn from Sara

I've paired with Sara, on and off, for about two years. Here is what I get from her that I do not get from any AI.

A real second perspective. Sara has opinions. They're informed. They're sometimes the opposite of mine. When she disagrees, she pushes back, and the push-back forces me to articulate why I think I'm right. Half the time, the articulation reveals that I'm wrong. The model never does this. The model has a tendency to agree, or at most to gently surface alternatives. It's not designed to make me feel uncomfortable, and the discomfort is the value.

A real second context. Sara remembers when we made a similar decision six months ago and why it broke. She remembers that the on-call person before us couldn't sleep for three nights because of a bug we wrote together. The AI has the codebase in its context but not the people in it, and most of the load-bearing decisions in software are about the people.

A real shared output. When Sara and I finish a session, both of us know how the new code works. With the AI, I get the code; the AI keeps no memory of the work; nobody else has any context. The next time the system breaks, I'm alone in a way I never am with Sara.

What I learn from Claude

Different things. Real things.

Speed. I'm probably twice as fast at writing functions with Claude as without. Sometimes more. The compounding effect of small speed improvements over an eight-hour day is genuinely substantial.

Patience. Claude is a phenomenal pair partner for the boring parts of work. Writing tests. Converting between formats. Setting up scaffolding. The kind of work where Sara, reasonably, would resent the time more than the work merits.

A willingness to be questioned. Sara is patient. Sara is also a person with finite tolerance for me asking "and what about this edge case? and this one? and this one?" Claude has infinite tolerance. I can interrogate a piece of code for thirty rounds without anyone getting tired. The depth of investigation I'm willing to do has gone up because the social cost of asking another question went to zero.

A second pass on my own code. This is the underrated one. Even when I write the code myself, I'm now in the habit of pasting it into Claude and asking "what would you change?" The suggestions are often wrong. But once a week, they catch something I'd missed. The value isn't the agreements; it's the rare, well-timed disagreement.

Where they overlap (and don't)

You'll notice the columns are largely not the same activities. That's the point. There is some overlap in the rough territory of "writing code", but the things each one is good at don't really collide. It's not a competition. It's a different setup.

The wrong question we keep asking

The wrong question is "how do we make AI pair programming feel more like pair programming with a human?" This is the question driving the design of half the AI coding tools today. Better memory. More personality. Conversational style. Casual feedback. The whole "your friendly AI co-worker" pitch.

It misses the asymmetry. Pair programming with a human is a social activity. The mechanism that makes it work — the second perspective, the discomfort, the shared accountability — is fundamentally about the other party being another full agent in the world. You can't simulate that with a model that has no stake in the outcome, no shared history with you, and no memory of last Tuesday.

The right question is the inverse: how do we use the AI for the things humans are bad at, and keep our humans for the things the AI can't touch. The right metric isn't "is my AI starting to feel like a person?" It's "did I make better calls today than I did yesterday?"

If the answer is yes, you're using the tool right. If the answer is "I'm typing faster but I'm not sure I'm building better things", you're using it wrong.

The honest synthesis

I still pair with Sara every Tuesday morning. Same time, same room, same coffee. Two hours a week of someone disagreeing with me out loud.

I use Claude for about three of every five hours of writing code. The math has been right for me for about a year.

Both are real. Neither replaces the other. The thing that needs to die isn't either of these activities — it's the framing that suggests they're the same kind of thing.

You're not pair programming with the AI. You're working with a very fast, very patient, surprisingly competent set of tools. That deserves its own name. The fact that we don't have one yet is part of why we keep getting the conversation wrong.

Call it tooling. Call it assisted writing. Call it whatever you want, except "pair programming". Save that phrase for the humans, who need it more than the AI does.