In pair programming, the experience of every member of the team can be spread to new member. This experience is always in sync with the code, because the "senior" of the pair knows how the code works and what the design is.
So what is the utility of design documentation in this case ?
UPDATE
I don't imply no design, I imply no documentation. With a team which practice pair programming I think that everybody is disposable, because everybody knows the code. If the senior developer leaves, I think that there is always at least one person who knows the code, because the experience was shared before.
Depends what you mean by "design documentation".
If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.
If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...
Those are the two main forms of documentation I've used in XP teams that pair on all production code.
The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.