Pair Programming (2 blogmarks)

My response to Kieran Murphy's post about how "pairing" with Claude (i.e. one human and one AI agent) does not constitute pair programming in a meaningful way.

I’ve yet to try it, but I feel bullish about two humans pairing on the orchestration of multiple agents.

Where pairing shines is the heightened level of engagement, opportunity to discuss edge cases, and learning patterns of the craft from one another. Pairing feels dull when you are in the doldrums of writing tedious code. AI coding agents take care of the latter so that you can do more of the former.

That’s my theory anyway.

I agree with Kieran's main point (you need two people to pair) and go a step further to suggest that pair programming is probably the best way for us to adapt to the new way of building software in the era of AI.

Justin describes some of ways that LLM coding agents used as pair programmers can lead to bad patterns in pair programming. In particular, one person taking over while the other person disengages or becomes a rubber stamp for their changes.

He then throws out some ideas for ways that LLM coding assistants can be improved with what we’ve learned over the years from person-to-person pairing.

My preference is what he describes here:

throttle down from the semi-autonomous "Agent" mode to the turn-based "Edit" or "Ask" modes. You'll go slower, and that's the point.

One suggestion is something we can do now (out-of-band or at least front-loaded).

Design agents to act with less self-confidence and more self-doubt. They should frequently stop to converse: validate why we're building this, solicit advice on the best approach, and express concern when we're going in the wrong direction

Tell the LLM you want to approach things this way, that you want to break the problem down and tease out any issues with the proposed approach. Engage in some back and forth, have it generate a plan, and then go from there.