Исходники, то есть текст - в гите

так и это не ново WYSIWYG давно придумали, вопрос договориться как должна выглядеть картинка на основе написанного текста и наоборот - и вот тут "нюансы" :)

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

Наоборот) генерация почти никогда не бывает лаконичной (читаемой). Ручками потом вычищать.

Да, скорее всего - одно направление, из кода в картинку

Ключевой момент - обсуждается не код, а картинка. Образ, которым все мыслят - картинка.

Так же как и с веб-интерфейсами. Никто не обсуждает куски HTML и JS

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

Поэтому для ide архитектора помимо рисовалки, редактора текста и транслятора между текстом и картинкой нужна ещё некая считалка, которая позволит оценить качество написанного. Это как раз тот самый дебагер, а котором разраб сидит over 9000 часов, и который никому кроме разраба и не нужен.

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

Ну так и качество наверное можно тоже проверить: если задать все граничные условия (внутрениие и внешние)

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

Именно. У нас есть ГОСТ, который можно просто вернуть как обязательство, понятно, что сразу будет тонна воплей, что ГОСТ говно, потому что совок, нет аджайла и прочее.
Но это обычно со стороны тех, кто хочет сильно сэкономить на качестве.

ГОСТ действительно говно))

Ген, если его грамотно готовить - отличная методология сразу со способом документирования и метпамоделью для архитектурного репозитория.

Давайте уж разделим архитектурные описания на две группы: того, что уже существует и эскизы будущей архитектуры. Первое станет as-a-code, рано или поздно. А вот фантазии и договоренности о том, как оно будет, просто по своей природе, будут обладать рядом сложно формализуемых свойств

Да

А если проест из AS в TOBE то как быть?

Это совсем частный случай: такой специальный to-be, который сделан из частей as-is на основе уже принятых раньше решений о выборе такого варианта реализации

Забить и ждать когда нужно будет переделывать по частям. Или просто жить как-то, как жили и раньше.

Ну т.е. вместо того, чтобы договориться о правилах игры - забить и наслаждаться свободным хаосом :) (что сейчас и имеем)

Или страдать и умереть в муках)

Ген, для любого производителя, любой стандарт - это боль и муки) а ещё убытки)