[makmanalp]

Usually pairing seems to work great to get you through things that seem like they're a slog. So you don't have to pair through everything, just the hard and boring bits. It helps to timebox it, and say it's going to be (e.g.) an hour long session to prevent it from taking forever and help focus. Even if you're not done, chances are you'll have made good progress. So, schedulingwise, it's a bit like a meeting.

The largest benefit I see is that having someone with you is like having more than double the focus and vigilance, since you're both there to help each other out and you'll both tell each other when you're leading yourselves astray, which doesn't happen when programming individually.

Pair-design also works great.

I think it's harder to be as productive in code review (and I think they aren't mutually exclusive anyway) because people tend to focus more on nitpick changes like style issues, and miss the larger design stuff.

[simonista]

Sure, but my question was in the context of the OP definition of "pair programming culture" as "a team that does nearly 100% pairing ... The day-to-day experience of programming is that of a day-long conversation with your pair"

I'm curious how other things that are intrinsically non-pair activities fit in.