A non-trivial programming assignment is difficult to write, and a good, robust marking scheme is even harder. At the university where I work (I'm what Americans would call a TA) we give our first years a supervised programming lab every week. It usually takes two or three semesters to get the bugs out of the task specifications, and that's with the lecturer and two to five TAs working together.

Programming tasks that have never been assigned to students are like software that hasn't been beta-tested: even if the designers and implementors are top-notch, there's still likely to be some unforeseen interaction with the environment and the users.

If cheating is worse in the US, it's unlikely to have anything to do with who does the grading; detecting cheats is really not that hard. It's more likely to be a combination of, firstly, a perceived disconnect between the task and the student's personal goals, and secondly, the general devaluing of intellectual skills that seems to be endemic in Anglophone culture.

I teach an introductory CS/intermediate Java course, and we use pair programming for most of our lab work -- it's not so much about saving marking time as about getting to give students better-quality feedback. We mark all our labs in class, so we get to quiz the students in person and let them tell us the reasons behind their design choices, but that means our marking time is fixed.

So what we do is mark each student on his or her comprehension of the solution, as demonstrated in the marking interview. Weaker students get little benefit from riding on the coattails of stronger students. We do find the odd strong student who's not willing to let his or her partner touch the codebase though. Pairs like this we either counsel or break up.

We also don't let students have the same partner more than three times during one semester, so they get practice at working with programmers of different skill levels.