в моём последнем проекте, нет не 1 XAML файл в CodeBehind частью.
Вся Visual'ная часть представлена в виде DataTemplate'ов, для которых можно задать соответствующий тип контекста данных
то есть, делаешь Model, затем берешь данные из модели и представляешь их в том виде, который ты бы хотел увидеть в интерфейсе.
Грубо, говоря если мне надо список представить в виде текста, то во ViewModel ты преобразуешь массив в текст и т.д.
для конкретной ViewModel можно создать интерфейс который будешь указать как контекст данных во ViewModel, это будет контрактом для верстальщика. Он будет видеть какие у интерфейса есть свойства и Command'ы и будет на них делать View.
У меня в конторе сами дизайнеры в XAML не верстают. они дают мне файлы в AI Формате, а я уже пилю на XAML

Rocketeer88888Сон Веры ПавловныВ иделе модель, вьюмодель и UI должны быть разнесены по разным сборкам.
Всё равно возникают проблемы и надо всё дебажить вместе. Т. е. должен быть человек, который разбирается во всём и любую часть может поправить. А значит, лучше, когда все части делает один и тот же человек, а не на конечное звено в производственной цепи (сборщика) скидывают проблемы все предшествующие.

Всяческие тесты тут помогают постольку-поскольку, и всё равно в конце должен быть человек, который "знает всё и может всё поправить ещё вчера сроки горят уьбю если не успеешь за две минуты и мне плевать, что мы на презентации, а все исполнители отсутствуют/в отпусках/уволились/заболели/умерли".

Специализация хороша при конвеерном производстве, когда штампуют одно и то же и все процессы можно отладить. Т. е. если вы делаете, например, сайы по шаблону с минимальными изменениями, то катит, а если каждый раз индивидуальный дизайн и значительные различия в технологиях (каждый раз что-то новое пробуете - ведь мир джаваскрипта меняется со скоростью один фреймворк и три мажорных версии в год), то при проблемах виноватых, как правило, не найти.
для того, чтоб такой подход работал нужно хорошо спроектировать всё с самого налача, иметь чёткие контракты для каждого слоя, тогда проблем не будет. Если какой то код не соотвествует контракту, значит тот кто его делал его правит, а кто в какой последовательности при этом пишет совершенно не важно. Вполне возможно, что UI будет сделан раньше даже Data Model.