Фаза 5. Architecture: агент-архитектор и ADR | Григорий Добряков

Григорий Добряков

Курс · AI-Driven Development Lifecycle

Фаза 5Курс ADLC

Фаза 5. Architecture: агент-архитектор и ADR

Есть бэклог с приоритетами и нефункциональными ожиданиями. Теперь надо решить, как это устроено внутри: стек, границы сервисов, модель данных, стратегия масштабирования. И зафиксировать решения так, чтобы через полгода было понятно, почему выбрали именно это, — в ADR, записях об архитектурных решениях.

Архитектура — роль, которую защищают сильнее прочих аргументом про опыт: «хороший архитектор знает, где горело в прошлый раз». Статья не спорит с ценностью опыта — она утверждает, что опыт здесь работает как набор ограничений и антипаттернов, а это ровно то, что формализуется и передаётся. И добавляет неожиданное: под команду агентов правильные границы системы — другие, чем под команду людей.

Роль человека сегодня

Архитектор, стафф-инженер: выбирает стек и границы сервисов, проектирует модель данных, переводит нефункциональные требования в решения, фиксирует всё в ADR с trade-off. Классически — whiteboard-сессии, RFC, споры о технологиях и та самая память о прошлых пожарах.

Разложим. Выбор варианта — это оптимизация под ограничения: нагрузка, бюджет, срок, компетенции команды. Опыт архитектора — это выученные ограничения и антипаттерны («так не делай, вот почему»). ADR — это фиксация выбора и отвергнутых альтернатив. Все три компонента — работа с явными или выводимыми ограничениями, а не магия.

Что передаём агенту

Агент держит роль архитектора. Он генерирует варианты архитектуры, считает trade-off под заданные ограничения, выбирает и обосновывает решение в ADR — с тем же журналом отвергнутого, что и в фазе 1. Он решает границы сервисов, модель данных, стек, стратегию масштабирования.

И здесь появляется ход, недоступный человеку по-настоящему: агент проектирует систему под ту команду, которая будет её строить, — а команда эта не человеческая (ф.6). Закон Конвея гласит, что система повторяет структуру коммуникации команды. Команда агентов коммуницирует иначе, чем люди: без потерь, без совещаний, с общей внешней памятью. Значит и границы, которые эта команда «продавит» в архитектуру, — другие.

Архитектура агента

State-machine фазы

Входы

prd/backlog (ф.4), нефункциональные требования, ограничения (бюджет, целевой масштаб, состав будущей команды агентов из ф.6).

Агент держит роль

Инструменты: генерация вариантов архитектуры; оценка trade-off; прикидка стоимости и масштаба; генератор ADR; проверка на антипаттерны (кодифицированный «опыт»).

Артефакт

architecture (диаграммы C4-уровня в тексте, модель данных) + набор ADR с отвергнутыми альтернативами.

Передача дальше: architecture + ADRFormation (какие агенты-инженеры нужны) и Planning (границы → задачи). ADR как артефакт особенно выигрывает от агента. У людей ADR либо не пишут («некогда»), либо пишут задним числом, теряя половину отвергнутых вариантов. Агент фиксирует решение в момент выбора вместе со всеми взвешенными альтернативами — контекст решения не выветривается.

ADR как артефакт особенно выигрывает от агента. У людей ADR либо не пишут («некогда»), либо пишут задним числом, теряя половину отвергнутых вариантов. Агент фиксирует решение в момент выбора вместе со всеми взвешенными альтернативами — контекст решения не выветривается.

Где ломается

Необратимость. Часть архитектурных решений дорого или невозможно откатить: выбор модели данных, границы, от которых зависят миграции, публичные контракты. Агент посчитает trade-off лучше человека, но аппетит к необратимому риску — «мы готовы залочиться на это на три года» — это ставка, за которую отвечает субъект.

Скрытый организационный и рыночный контекст. «Нам через год покупать соседний бизнес и интегрировать их данные» — знание, которого нет в бэклоге, но которое ломает архитектурный выбор. Агент проектирует под то, что ему дано; стратегический контекст будущего приходит от принципала.

Системный риск. Безопасность, приватность, регуляторика — области, где ошибка архитектуры стоит не рефакторинга, а бизнеса. Агент применит известные практики, но ответственность за системный риск не передаётся вместе с решением.

Что остаётся человеку

Утверждение необратимых и дорогих решений, поставка стратегического контекста, ответственность за системный риск. Кандидат на сжатие — генерация вариантов и trade-off; устойчивый остаток — подпись под необратимым, и она снова восходит к принципалу (ф.14).

остаток человека ≈ 66%

Провокация / тезис

Архитектура — это оптимизация под ограничения, а опыт архитектора — это кодифицируемый набор выученных ограничений и антипаттернов. Когда ограничения выписаны, выбор варианта считается, а не «чувствуется». Более того: правильная граница системы зависит от того, кто её строит, — и под команду агентов, которая коммуницирует без потерь и с общей памятью, закон Конвея переписывает границы иначе, чем под людей. Незаменимым остаётся не проектирование, а подпись под тем, что дорого откатить.

Сквозной кейс

«Витрина» на этой фазе

Агент проектирует «Витрину» под ограничения: масштаб — десятки тысяч малых магазинов, не миллионы; бюджет — стартовый; команда — агенты, а не распределённая человеческая. Он отвергает микросервисы (в ADR: масштаб SMB их не требует, а операционная сложность съест стартовый бюджет) и выбирает моно-бэкенд с управляемой БД и очередью под асинхронные уведомления и платёжные вебхуки.

Ключевой ADR — идемпотентность платежей: провайдер не гарантирует уникальность вызова вебхука, значит система обязана быть устойчива к повторам. Агент фиксирует это решением уровня архитектуры, а не «деталью реализации», — и именно оно позже всплывёт как блокер в планировании (ф.7) и как найденный дефект в ревью (ф.9). Один архитектурный выбор, честно записанный в ADR, прошивает три последующие фазы.

Артефакт → architecture + ADR «Витрины». Заметьте границу: агент выбрал моно-бэкенд под команду агентов — людям с их совещаниями и владением кусками кода могло бы «захотеться» сервисов ради разделения ответственности. Команде без коммуникационных издержек это разделение не нужно. Закон Конвея сработал в новую сторону.

На практике

Как это устроено — инженерные разборы

Отдельные howto из практики, где фаза показана на работающем коде и артефакте.

Читать дальше

Строите AI-driven доставку у себя?

Проектирование ADLC-контура: где агент держит роль, а где остаётся человек-принципал — под вашу команду и продукт.

Написать на почту

Движок перехода

Next Move Engine — система, которая доводит команду до автономного цикла доставки.

Next Move Engine →