I haven't done much pair programming, but when I've been the co-pilot, I watch what is being written and think about what else needs to be done. If some critical thing gets missed, or I think the code isn't going to do what it's supposed to, I speak up. (That includes syntax, but also logic.) I sometimes (rarely) make suggestions about refactoring or tests that need to be done.
I will admit, though, that for a while we jokingly called it 'peer programming' because you were just peering over someone's shoulder. We had a cowboy coder that taught us a LOT of stuff in the short time he was here and 'peer programming' was a large part of that. His time here was disruptive, but I think the whole team is a lot more productive thanks to his short employment. (And his disruptions were mostly him trying to convince everyone to do things a better way.)
I will admit, though, that for a while we jokingly called it 'peer programming' because you were just peering over someone's shoulder. We had a cowboy coder that taught us a LOT of stuff in the short time he was here and 'peer programming' was a large part of that. His time here was disruptive, but I think the whole team is a lot more productive thanks to his short employment. (And his disruptions were mostly him trying to convince everyone to do things a better way.)