Дублирование логики при работе с агенами
Развивая мысль модульности и финансовой оценки изменений при применении агентов стоит затронуть тему дублирования логики.
Протечка абстракций может содержаться не только в существующей реализации, но и в самой постановке. Причем в постановке она может содержаться неявно, автор требования может этого не предполагать, но агент примет собственное решение.
Выглядит так, что этому в меньшей степени могут быть подтвержены OpenSource проекты, так как в нихчастой единственный репозиторий. В организациях же репозитории раздельны как физически, так и организационно.
Таким образом, при постановке задачи без явного описания модели предметной области и четко и явно прописанных границ, агент может быть склонен решать задачу используя свое представление о модели. И он решит задачу, при этом напишет собственную логику вместо использования внешнего API для этой логики, так как не знает о наличии этой логики в соседнем репозитории.
Это, в свою очередь:
1. Увеличивает общий объем кода и общий объем изменений за счет дублирования функциональности в различных частях организации
2. Приводит к необходимости координации изменений в будущем, если различные реализации одной и той же логики участвуют в одном и том же глобальном бизнес-инварианте (используются для расчета налоговой базы, например)
При этом важно отметить, что сама по себе слабая фиксация границ не обязательно ведет к появлению дублирования, однако при этом значительно повышает вероятность роста количества токенов за счет того, что оставляет более широкие границы при анализе вариантов и, как следствие, повышение объема рассуждений. То есть единицей проблемы становится область видимости агента относительно области действия инварианта.
Если рассмотреть это через призму одной из задач архитектуры, – «снижение стоимости последующих изменений», то ключевой вывод может звучать так:
Развивая мысль модульности и финансовой оценки изменений при применении агентов стоит затронуть тему дублирования логики.
Протечка абстракций может содержаться не только в существующей реализации, но и в самой постановке. Причем в постановке она может содержаться неявно, автор требования может этого не предполагать, но агент примет собственное решение.
Выглядит так, что этому в меньшей степени могут быть подтвержены OpenSource проекты, так как в нихчастой единственный репозиторий. В организациях же репозитории раздельны как физически, так и организационно.
Таким образом, при постановке задачи без явного описания модели предметной области и четко и явно прописанных границ, агент может быть склонен решать задачу используя свое представление о модели. И он решит задачу, при этом напишет собственную логику вместо использования внешнего API для этой логики, так как не знает о наличии этой логики в соседнем репозитории.
Это, в свою очередь:
1. Увеличивает общий объем кода и общий объем изменений за счет дублирования функциональности в различных частях организации
2. Приводит к необходимости координации изменений в будущем, если различные реализации одной и той же логики участвуют в одном и том же глобальном бизнес-инварианте (используются для расчета налоговой базы, например)
При этом важно отметить, что сама по себе слабая фиксация границ не обязательно ведет к появлению дублирования, однако при этом значительно повышает вероятность роста количества токенов за счет того, что оставляет более широкие границы при анализе вариантов и, как следствие, повышение объема рассуждений. То есть единицей проблемы становится область видимости агента относительно области действия инварианта.
Если рассмотреть это через призму одной из задач архитектуры, – «снижение стоимости последующих изменений», то ключевой вывод может звучать так:
Неясная граница ответственности снижает вероятность обнаружить существующего владельца инварианта. Агент может удешевить текущую задачу локальной реализацией, одновременно повысив ожидаемую стоимость будущих изменений и риск расхождения поведения.