Это мое мнение, с ним можно спорить. Аналитику не нужно уметь писать код — но понимать его на уровне чтения "Джуна разработчика" необходимо, чтобы перестать быть почтальоном между бизнесом и разработчиком. Это знание позволяет отсекать невыполнимые требования, предлагать обходные пути в процессе обсуждения.

Цель аналитика ответить на вопросы работы системы, удовлетворить любопытство. А потом сделать так, чтоб взлетела требуемая функциональность.

Аналитик с архитектурным мышлением не замещает разработчика, но становится инженером требований — задает сценарные вопросы, декомпозирует задачи и тестирует не клики, а жизненные сценарии. Это экономит бюджет и нервы команды. Такой аналитик будет решать концептуальные вопросы с пользователями, а не умозрительные бантики.

Чего не стоит делать аналитику в разработке, даже если он "немного понимает код" - писать в ТЗ и говорить пользователям как однозначно в "объектах" работает система, не посоветовавшись с разработкой. Аналитик видит проблему и предлагает сделать (новый регистр, фоновое задание, разделение документа). Разработчик решает как это сделать с учетом всех технических ограничений. Нарушение границ участников команды ведет к костылям, багам и выгоранию команды