Эволюция Закона Конвея и социальная сложность ИИ-агентов

Долгое время Закон Конвея служил надежным инструментом организационного проектирования. Формируя команды вокруг ограниченных контекстов, архитекторы направляли коммуникации так, чтобы код естественным образом разделялся на независимые сервисы. Этот процесс, известный как «Обратный маневр Конвея», опирался на фундаментальную предпосылку о том, что люди, пишущие код, присутствовали в коммуникационной структуре.

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

Что делать?

Превратить границы архитектуры в проверяемые ограничения
Неформальные договоренности плохо масштабируются в среде, где код создают не только люди. Наверное, это и есть истинный барьер, почему тормозит внедрение ИИ в задачи, в которых важен широкий контент и при этом достаточно высокая точность принимаемых решений. И если раньше можно было как-то схалтурить, то теперь реально нужны:
• контрактные тесты между сервисами и модулями
• архитектурные тесты на допустимые направления зависимостей
• правила импорта, запрещающие доступ к внутренним пакетам другого контекста
• фитнес-функции в CI/CD, проверяющие соблюдение архитектурных инвариантов
• политики доступа к репозиториям, каталогам, инфраструктурным модулям и секретам

Разделить глобальное состояние инфраструктуры
Особенно опасной становится инфраструктура с единым глобальным состоянием, – любое изменение затрагивает общую область, требует блокировки и увеличивает риск побочных эффектов. С кодом схоже, но тут есть риск конкурирующими изменениями положить всю инфру. Снова не получится схалтурить как раньше, теперь придется:
• разделять состояние инфры по доменам и жизненному циклу ресурсов
• выделять независимые слои в инфре
• ограничивать права агента только теми ресурсами, которые относятся к его задаче
• строить зависимости между состояниями через явные выходные данные и контракты

Спроектировать область видимости агента
ИИ-агент не должен быть универсальным солдатом с правом менять все, что ему заблогорассудится. Наиболее надежная модель – это дать каждому агенту ограниченную область ответственности, совпадающую с границами конкретной команды или домена. И снова не получится схалтурить. Если команда отвечает за один продуктовый поток, сервис или bounded context, агент этой команды должен работать в тех же границах:
• иметь доступ только к нужным репозиториям и каталогам
• менять только компоненты своего домена
• использовать только разрешенные интеграции
• работать с заранее определенными контрактами соседних систем

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

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