совершенно верно. Незнание предметной области приводит в итоге к костылям в коде. Мы новым разработчикам читаем обязательную лекцию по предметной области проекта

Абстракции нельзя уточнять через аналитика? Вы не понимаете, что не каждая предметная область доступна для быстрого "вникания" ради одного проекта?

до уровня аналитика и не надо. но иметь общее прелставление о процессах и причинах событий разработчик обязан иметь

перед решенеим каждой задачи - консультация с аналитикаом must have

Я считаю что аналитик не должен указывать как писать код, получается порочный круг: псеводокод в постановке, а разработчик это тупой кодер.
На эту тему выше уже высказывались к чему такой подход приводит.
К счастью у нас не “один проект”, а продукт который развивается третье десятилетие.

Задача аналитика в том чтобы зафиксировать сценарии, требования, ограничения на натуральном языке. Разобраться в предметной области, профильтровать информацию, донести её до разработчика.

В такой постановке у вас выпадает звено системного аналитика, и его функции вы переносите на разраба. В принципе, в тиражной разработке на 3м десятилетии это возможно. Я думал, речь о разовом заказном проекте (там эти функции имхо проще переносить на бизнес-аналитика или 1го специально выделенного разраба).

Системный аналитик описывает алгоритмы преобразования данных, но на верхнем уровне. Естественно эти алгоритмы не будут оптимальными (у СА ограниченные знания в алгоритмах и опыт их применения + недостаток знаний свойств технологий). Именно в момент чтения спецификации разработчик должен понять, чего добивается аналитик и предложить альтернативу, пускай на словах, после чего имплементировать её в код.
Аналитик протаптывает дорожку для разработчика, но последний должен тоже держать на себе часть ответственности, где надо сокращать, а где надо усложнять маршрут. Из разработчика должны порождаться требования, иначе всё будет как в институте: "если аудитория не задаёт вопросов, то ей либо всё понятно, либо ничего не понятно".

Чем опытней аналитик, тем с большей вероятностью он предложит оптимальный алгоритм разработчику (либо научится согласовывать заранее).

Но надо помнить, что разработка для СА - это предметная область и он начинает заниматься не своей работой для повышения продуктивности команды в целом. Базовый СА пойдёт к разработчику и спросит, как тут сделать, по каждому шагу. А опытный накидает план и пойдёт договариваться и уточнять детали. Совсем опытному с глубокими знаниями предметной области разработки можно написать ТР, отдать его джунам и если они выполнят всё в точности, то всё заработает.

Я считаю что у аналитика и разработчика все-таки нескольк оразные поляны деятельости, лишь частично пересекающиеся.
Аналитик отвечает за вопрос “что надо и почему”, разработчик “как правильно сделать”

Что и почему - это про бизнес-аналитика. Системный аналитик - это про "как", но используя чужую экспертизу. Он собирает мнения, убирает противоречия и складывает всё в решение.

Аналитики в IT невольно начинают специализироваться в предметную область IT, т.к. это позволяет быстрее и качественнее делать свою работу. Но в этот момент надо найти приемлемый уровень абстракции и правильно выполнять последовательность согласований.

Как пример, есть системные аналитики, которые участвуют в создании ядерной электростанции. результатом их работы является документация проекта с описанием почему, зачем, а также "структура электростанции вплоть до последнего болтика". При этом они не знают как её строить, но собирают экспертизу и информацию от инженеров, формируя общий пакет документов. Иногда в этом пакете вообще нет ни единой схемы, выполненной аналитиком.

Покрытие кода комментами может помочь. Желательно со ссылками к описанию - номер задачи в jira, как пример. Это и для ревью удобно и потом арх/аналитик и тп могут попробовать понять что хотели и что получили. Но! Это время :)

За комментами тим лид должен следить, при ревью

Тимлиды были спущены в биореактор первым делом, так как такой роли в скраме нет. Кто такой тимлид в скрам-аджайле?

Тогда арх :) арх надзор никто не отменял, а что в него включено - никто не декларировал. Изначально - правила сдачи - код покрыт комментами. Если никто за разработчиками и кодом не смотрит, то ожидать чуда не надо :) для начала - снять стек-трейс процесса и начать с верхнеуровневого покрытия  комментами процедур/функций/апи разработчиком

Пока пишет начнет понимать

Но будет много негатива :)

тоже так себе решение, пожалейте архитектора, проводить ревью кода десятков команд. на бедном архитекторе все процессы и встанут.