tl;dr: This isn't an either/or sort of situation. You have a lot of options for structuring the exercise.
There are a lot of possibilities and which works best depends on the specifics of your situation. Don't lose track of the fact that your goal is educational, however, and not code production. If the students learn but not much code gets produced it can still be a success depending on other parameters. Since I'm going to try to cover a lot of options it will be something of an IFTTT answer.
For all of the cases below it might be best if you don't have one triple or one solo and the rest pairs. It will probably work better for your own learning about this situation if you have, say, three triples and the rest paired or three singles. You then get a better picture of how pairing itself differs from other options.
If you are willing to have some programmers work alone
A few days prior to the exercise let each student make a written bid on whether they want to pair or not. Have them give reasons for their preference. Let them know that their preference may not be able to be honored. Look at the bids and decide based on their reasons and your judgement about what would serve everyone best.
If you have a single superstar who always makes perfect marks
It is possible that he/she doesn't actually need the practice of this lab so give that person a different task, perhaps as a resource to the remaining pairs, answering questions, prompting, helping you watch over the flock. Someone needs to answer questions as they arise anyway and it might be an opportunity for a person to learn at a more meta level. If your superstar has expressed an interest in teaching eventually this might have additional payoffs for the person. Likewise if he/she is a language lawyer it might help them dig deep into their knowledge on the fly.
If you have a single struggler (or 3)
You could put him/her into a triple with others not terribly far advanced from that person's state. In this case, be prepared to be a fourth member of that team to help them keep the situation moving and the process easy and friendly. Don't let the struggler avoid the programmer role. Your choice of teams here might have to depend on personal qualities. Don't put him/her with the arrogant monster.
If the lab is long (say 3+ hours) or if each pair contributes differently to a larger goal
This one is a bit riskier with youngsters but works fine with professionals. Choose teams in any way that suits you (see above) and let the process run for a while (half hour to one hour). It needs to be long enough that switching roles has happened a few times. Then change the teams. Note that some people will move to a team with new code they haven't yet seen (the risk factor). At the switch point, the current driver stays with the code and the navigator(s) find new seats. The current driver for that code just continues after the break and the new navigators(s) spend some time catching up. If a person has been solo or in a triple in one iteration they are in a pair for the next. In many ways this is the most realistic scenario and matches how pairing is done in organizations. The advantage of this in the classroom is that students learn to read and understand new code - a useful skill on its own. However, you may need to map out in advance who the pairs/triples will be for each segment. Each student caries a card with them listing who they worked with and if you want to do peer evaluation, each can mark at the end who they thought was their most effective partner. If they work with at least five others, I would ask them to mark their two most effective partners. Don't ask for criticism of partners, just for who contributed the most. Make sure they know in advance that this will happen - to encourage good behavior. A more elaborate peer evaluation is to also ask why they marked the people they did - who was most effective and why.
In any case
Don't neglect to set aside time at the end or in the next session to have a retrospective on both the project itself and the process. You could also ask for a written assessment from each student on what worked and what didn't.
And don't neglect...
Don't lose track of the purpose and benefit of pairing. The driver takes a tactical, microscopic view of the code being produced and the navigator takes a strategic, macroscopic view. Work to keep this concept going as well as possible. It is the essence.
Additional advice
If you poll the student preferences as suggested above (even in conjunction with a different option) it would be good to announce your decisions a day or so in advance when you can't meet all desires. This gives you a chance to explain (privately) to some why their choice couldn't be honored. "I really need you to ..."
And be clear in your own mind, and let the students know, what is the main goal of this exercise. Is the project itself more important or is learning something about the process. When you have to make compromises do so with that goal in mind.
