Следующая заметка про записи архитектурных решений продолжает темы, затронутые в
Я хочу поделиться результатами недавнего опроса в тг.-канале Архитектура ИТ-решений и некоторыми размышлениями над комментариями к нему. На данный момент опрос собрал почти тысячу голосов, причем варианты не были взаимоисключающими (каждый участник мог выбрать несколько, картинка будет ниже).
Вопрос звучал так:
Как вы относитесь к генерации LLM-ками записей архитектурных решений ADRs
Меньше трети голосов попадают в технические категории:
-
- 282( 1%) — Хочу посмотреть результаты опроса
- 12(28%) — Свой вариант (напишу в комментарии)
Т.е. практически около 700 ответов на текущий момент затрагивают содержательные вопросы. Их можно разбить на две большие группы. Первая выражает отношение к генерации architecture decision records генеративным ИИ, а вторая к тому, как это лучше делать. Давайте посмотрим на каждую группу отдельно.
В первой группе распределение следующие. Скептиков довольно много. В эту категорию я определил проголосовавших за вариант
-
- 35( 3%) — Скептически отношусь к ADRs
- 47( 4%) — Крайне отрицательно! (к генерации ADRs LLM-ками)
- 188(19%) – Настороженно
Всего эта группа объединяет 269 голосов, что больше категории приверженцев, назвавших генерацию ADRs нормальной практикой 215(21%). В комментариях меня пожурили за некоторый перекос в вариантах ответа в сторону скептиков. Это действительно так! Но здесь мне важно количество людей, даже не относительные значение, а конкретное число среди подписчиков, которые высказывают настороженное отношение. Кстати, в комментах было достаточно количество объяснений такого отношения.
Но давайте перейдем к тем, кто отвечал на вопрос как это делать. Большое количество голосов сосредоточенно здесь. И вероятно еще некоторая часть приверженцев отметилась только в этих категориях. Но давайте посмотрим какие они
-
- 248(25%) – считают, что это должен быть итерационный процесс и почти столько же
- 239(24%) – что ИИ-агенту следует уточнять у человека детали
- 143(14%) – отметили, что модель должна создаваться ADR анализируя код, PR, протокол встречи… И это на мой взгляд удивительно, потому как в инфосфере сейчас продвигается именно этот сценарий. В нем агент сидит вместе с нами на совещании и записывает либо же анализирует изменения в репозитории. В общем, в незаметном режиме поставляет нам проекты ADRs. Впрочем, у меня этот сценарий тоже вызывает вопросы, как и многие другие фантазии в стиле строчки из детства: «Вкалывают роботы, счастлив человек». Вариант, на который я втайне надеялся набрал наименьшее количество голосов в этой группе
- 58( 5%) — Можно, но для ADRs определенного типа
О нем я говорил на вебинаре Модернизация процесса проектирования. И главный мой посыл состоял в том, что архитектурные решения бывают разные.
Часто мы сталкиваемся с решениями, закрепляющими выбор технологий. Они не особо сложные и задаются контекстом. Я уже встречал пару раз агентские навыки, которые подсказывают технологии. Например, на основании частной версии тех.радара в стиле radar.thoughtworks. И главная проблема такого типа решений в том, что кроме выбора технологий они могут включать в себя и другие аспекты. Например, мы пишем решение о выделении в отдельный сервис обработчика некоторого вида запросов и тут уточняем, что в качестве технологии для такого обработчика будем использовать OpenSearch. Без дополнительных указаний модель может запутаться, решив, что решение это касается только выбора технологий и не обратив внимание на то, что это же решение описывает декомпозицию. А еще такое решение, наверняка вызовет потребность в получении данных из других компонент системы и повлечет выбор технологий для CDC и передачи событий. Вообще, системе записей архитектурных решений явно не хватает механизма меток, подсвечивающих как типы решения, так и другие свойства. Те же статусы можно реализовать подобным образом. Поговорим об этом на курсе Проектирование ИТ-решений с использованием Cursor AI.
Другие типы решений не так хорошо подаются генерации. Например, Philippe Kruchten в своей работе An Ontology of Architectural Design Decisions in Software-Intensive Systems выделял группу Executive decisions – решений больше связанных с бизнес-средой, процессом или методологией. Об этом модель может вообще ничего не знать и вряд ли окажется на высоте.
Резюмирую свою мысль и вернусь к результатам опроса. Если бы мне потребовалось бы формулировать навык архитектурных решений для ИИ-агента, я бы реализовал его в виде конвейера, проверяя на каждом шаге – не несет ли решение в себе те или иные свойства (выбор технологии, декомпозиция, определение источника данных и т.п.). И для каждого уточнял бы наличие необходимых данных в запросе и необходимые внешние ресурсы и инструменты.
Что еще мне кажется важным сказать об опросе. Тема затронула многих (39 комментариев непосредственно под вопрос, еще больше в группе обсуждения). Главная мысль – агент может и сформулирует тезисы, которые лень писать и даже подскажет какие-то неочевидные варианты или альтернативы, но не сможет принять решение и отвечать за него. Даже архитектор часто не имеет полномочий на единоличное принятие архитектурных решений. Не стоит ждать, что это доверят программе. Четких и верифицируемых критериев «правильности» принятого решения пока не предвидится. А без этого не научить ИИ-агента принимать решения не оценить их качество в бесчеловечном режиме не выйдет.
