Роль Solution Architect в эру AI-агентов

Введение

В апреле 2026 года глава Google Сундар Пичаи сказал, что 75% нового кода Google сгенерировано AI. Динамика: 25% в начале 2024 года, 50% к концу 2025 года, 75% к апрелю 2026 года.

Согласно Sonar 2026 State of Code Developer Survey, 96% разработчиков не доверяют функциональной корректности AI-кода полностью. 95% тратят время на его проверку, тестирование и исправление, а 38% считают такое ревью более трудоемким, чем проверку кода, написанного человеком. Генерация кода подешевела, контроль за ним — нет.

Thoughtworks в Technology Radar vol. 34 (апрель 2026) ввел термин codebase cognitive debt — разрыв в понимании между человеком и кодовой базой, который растет по мере того, как AI генерирует все больший объем кода а человек не поспевает.

Узкое место производственного процесса сместилось с написания спецификаций и кода на постановку задачи AI (intent) и контроль генерации (review): что именно должна делать система, в каких границах и кто проверяет, что AI-агент сделал именно это. Код производится быстрее, чем кто-либо успевает подтвердить его соответствие требованиям. Качество, стабильность и сопровождаемость держатся на том, кто и как организует постановку и проверку. Это зона ответственности архитектуры.

Квалификация архитектора смещается от проектирования общих и детальных архитектурных решений к владению контекстом системы, спецификациями и AI-платформой.

В этой статье я, Алексей Соболеков, архитектор решений, разберу изменение роли архитектора в агентной разработке. Я прошел три модели архитектурного процесса.

В одном крупном ритейлере функция архитекторов решений была сервисной: один архитектор вел от 2 до 8 инициатив, сил хватало только на обязательные C4-диаграммы.

В другой розничной сети, напротив, выделенных архитекторов решений не было — их роль выполняли ИТ-руководители. В проекте прогнозирования и пополнения (F&R) архитектурная функция выросла с нуля до 5 архитекторов, покрытие инициатив расширилось. Но чем полнее становился процесс, тем больше времени он занимал: архитектура устранила хаос и сама стала ограничивать пропускную способность разработки.

В текущем моем проекте F&R часть проектирования уже выполняют AI-агенты: формируют связанные спецификации, проверяют их на противоречия и готовят материалы к человеческому ревью.

Агентная разработка для меня — не теоретическая модель, а следующий этап этой эволюции.

Как была устроена роль архитектора до агентов

Шесть ролей производят артефакты руками:

1. Анализ пишет требования в Confluence,

2. Архитектор прикладывает к ним диаграммы HLD, C4 и ADR,

3. Дизайн — UI/UX макеты,

4. Разработка и тестирование — пишут код и тест-кейсы в Git,

5. DevOps — настраивает инфраструктуру.

Целостное описание системы располагается в разных инструментах и форматах.

Загрузка архитектора в такой модели неравномерна: максимум приходится на старт инициативы — разработку и согласование верхнеуровневой архитектуры (High-Level Design), затем следуют точечные включения — проработки компонентов (Low-Level Design, C4). Ревью привязано к отдельным архитектурно значимым решениям, которые оформляются как Architecture Decision Record (ADR).

Цену этой модели я видел в цифрах. В портфеле из 219 инициатив крупного ритейлера архитектор присутствовал в 29% инициатив. Средняя загрузка — 0,38 FTE в активный месяц против 0,82-0,88 у аналитика и разработчика. Один архитектор вел от 2 до 8 инициатив одновременно. 43% трудозатрат приходились на первую треть жизни инициативы, а в ресурсном плане 18-месячного проекта архитектор был занят 6 месяцев из 18.

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

2025-2026: переход от vibe coding к spec-driven

Перед архитектором в 2025-2026 годах стояли три варианта адаптации:

• Остаться автором диаграмм и полагаться на ручное ревью постфактум — с фрагментарным участием;

• Развивать vibe coding без промежуточной спецификации;

• Стать автором исполняемой спецификации, которую агент выполняет, а человек проверяет.

Шон Гроув, исследователь OpenAI, в докладе «The New Code» на AI Engineer World’s Fair 2025 (видео доклада) так сформулировал аргументы за переход к spec-driven подходу:

• Промптинг практически умер, на следующем уровне вы будете писать спецификации;

• Фиксация спецификаций в письменном виде делает их полезными для LLM, а заодно помогает людям договориться о них;

• Спецификации важнее кода: слишком много нюансов и знаний теряется, если остается только код.

 По оценке Гроува, код — это 10-20% ценности, которую создает инженер, остальные 80-90% — структурированная коммуникация: разговоры с пользователями, формулировка целей, планы, их обсуждение с коллегами, проверка результата на соответствие целям.

Классификация Биргитты Бекелер (Thoughtworks) делит spec-driven development на три уровня:

• spec-first — спецификация пишется до кода и после генерации не обязана жить;

• spec-anchored — спецификация живет вместе с кодом и остается точкой синхронизации при каждом изменении;

• spec-as-source — код генерируется из спецификации и вручную не правится.

Для архитектурной работы spec-first не подходит — он для одноразовых задач без длинного жизненного цикла. Spec-as-source еще недостаточно развит из-за незрелости инструментов и недетерминизма генерации. Остается spec-anchored — спецификация, живущая синхронно с кодом.

Изменение роли: от автора диаграмм к инженеру контекста

В целевой агентной модели между ролями и инструментами появляется слой AI-платформы с агентами по ролям. Люди перестают производить артефакты руками и передают агентам намерение и границы. Артефакты производят агенты и ведут их как код в Git. Confluence уходит из производственного процесса, остается каналом согласования с внешними заказчиками.

На моем текущем проекте это уже работает так: процесс аналитики — от брифа через user story map, use cases, объектную модель и функциональные требования до LLD, С4, ADR, dev-spec — проходит в одной сессии агента и одной git-ветке. Требования переехали из Confluence в GitLab. Ревью выполняется при помощи агента, владеющего полным контекстом проекта.

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

Контекст здесь — это конкретные артефакты. Правила процесса живут в файлах инструкций агента (AGENTS.md, CLAUDE.md), доменные знания — в подключаемых скиллах, актуальные данные приходят через MCP-интеграции, принятые ADR становятся входом агента при генерации.

Агентный процесс приносит архитектору новый объект владения — AI-платформу: набор агентов по ролям и их оркестрация, механизмы подачи контекста, доступ команд к агентам без ручной настройки, квоты и мониторинг.

У AI-платформы есть операционная стоимость — инференс. Расход токенов входит в стоимость владения решением (TCO) наравне с затратами на сервера и хранилища. Каждый прогон, каждое агентное ревью и каждый повтор генерации стоит денег.

Раздутый контекст ухудшает не только точность работы AI, но и экономику — лишние документы в контексте оплачиваются при каждом вызове. Кто владеет структурой AI-платформы и бюджетом инференса — открытый вопрос. Архитектор тут как минимум определяет состав агентов, правила контекста и точки контроля. Расход токенов на фичу — метрика, которую стоит включать в каждый проект.

Еще одна метрика из моей практики — AI Time Saved: после каждой фичи фиксируется в Jira, насколько сократилось время на задачу. Статистика еще накапливается, но по ощущениям, скорость значительно выше, чем в традиционном подходе.

Агентный процесс меняет и профиль загрузки. Генерация артефактов — HLD, C4, ADR, черновиков спецификаций — дешевеет и ускоряется, но каждый артефакт агента требует ревью, которое нельзя сделать один раз на старте и забыть.

Как это выглядит на практике

Для системы управления цепями поставок крупного ритейлера мы за 2 недели построили прототип из двух частей: расчетное ядро (Airflow, Spark, ClickHouse) и веб-интерфейс (Vue 3, BFF, витрины ClickHouse). Спецификации писались как вход для агентов по методике SPDD: каждое требование имеет стабильный идентификатор и проверяемый критерий приемки, идентификатор связывает промпт разработки, код и тест. Требование «табличные операции до 1 секунды» трассируется в нагрузочный сценарий и в метрику стенда — спецификация исполняема на всем пути от постановки до замера.

Нагрузочное тестирование закрыло гипотезу цифрами. На профиле 500 тысяч заявок расчет сформировал 4,7 млн цепей поставок. Расчетный конвейер занял 43-62 секунды при SLA 45 минут. UI держал P95 76-230 мс на табличных операциях при нормативе 1 секунда, 30 и 50 одновременных пользователях, без кэша и без ошибок. Масштабирование измерено, а не задекларировано: рост почти линеен до 8 воркеров Spark (эффективность 92%), дальше упор в скорость записи ClickHouse — его снял переход с 2 на 4 шарда. Стенд в облаке стоил около 93 тысяч рублей в месяц — цена проверки архитектурной гипотезы до старта продуктивной разработки.

Роль архитектора в этом кейсе — не диаграммы, написать проверяемую спецификацию, задать агентам контекст и границы, принять результат по метрикам стенда, оптимизировать архитектуру, прогнать цикл заново.

Цена изменений

Изменение роли архитектора не бесплатно. Проектирование того, какое знание системы попадает в контекст агента и в каком виде, и системное ревью агентного выхода требуют компетенций, которые раньше не входили в профиль архитектора.

AI-агенты требуют тщательного структурирования информации. Репозиторий перестает быть хранилищем только кода и становится носителем контекста проекта: в корне — общие инструкции агента (CLAUDE.md), в папках — спецификации, контракты API, модель данных, архитектурные решения, планы, скиллы с доменными знаниями, шаблоны документов и hooks с обязательными проверками. Структуру этого репозитория проектирует архитектор: чего нет в репозитории по понятному пути — того нет и в контексте агента.

Объем ревью растет вместе со скоростью, с которой агент производит черновики: точечная проверка артефактов нескольких инициатив не масштабируется на постоянный поток агентного вывода. Делегируя агенту рутинные ревью, архитектор рискует потерять понимание системы в деталях (cognitive debt).

Удержать растущий объем ревью помогают детерминированные проверки до человека: линтеры, тесты, валидация схем и контрактов. Ревью человека — последний барьер, а не первый фильтр. Правило: не можешь проверить — не выпускай.

На моем проекте этот барьер устроен так: ревью-агент владеет всем контекстом: устав проекта, рабочие процессы, шаблоны документов, бизнес-требования, спецификации, архитектура, модель данных, кодовая база.  Он анализирует спецификации до того, как артефакт попадает человеку, вердикты – Critical/High/Medium/Low. Спецификация не уходит в разработку, пока не пройдет согласование. Агентное ревью не заменяет человеческое, но оно фокусирует архитектора на том, что важно.

AI-агент склонен проектировать систему «на вырост». В одном из ревью модели политик агент предложил версионность сущностей, отдельный механизм разрешения конфликтов, контроль пересечения периодов и расширенную модель аудита. Все предложения выглядели архитектурно обоснованными. Но часть из них отсутствовала в бизнес-требованиях и значительно увеличивала сложность первой версии.

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

Агентный подход применим не везде. Он окупается при постоянном потоке инициатив, параллельных командах и внедренном агентном процессе с барьером проверки перед разработкой.

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

Постоянный контроль агентного выхода имеет смысл там, где объем генерируемых артефактов превышает пропускную способность точечной проверки.

Что не изменилось

После двух лет vibe coding сообщество возвращается к инженерным практикам: ясная архитектура и модель данных, критерии качества, тестируемость, DORA-метрики в 2026 году актуальны не меньше, чем до появления кодогенерирующих агентов.

Классические паттерны проектирования (design patterns), принципы чистого кода, DRY, KISS, YAGNI, SRP, декомпозиция по bounded context из DDD — применимы не только к коду, но и к спецификациям, которые этот код порождают. Спецификация с дублированием требований или без выделенных границ ответственности дает агенту противоречивый вход и непредсказуемый результат.

Компромиссы между SLA и TCO, границы владения данными, нефункциональные требования по нагрузке и отказоустойчивости — предмет архитектурной работы независимо от того, кто пишет код, человек или агент. Агент меняет скорость производства артефактов и профиль загрузки архитектора, но не отменяет необходимость решать, где проходит граница системы, и кто владеет данными на каждом ее участке.

Из моей практики: агентный процесс люди принимают неравномерно. Одни выстраивают контекст агентов, вчитываются в сгенерированные спецификаи и код, отбрасывают лишнее и берут нужное. Другие работают по-старому — одноразовыми промптами без спецификаций. Часть команд и заказчик по-прежнему живут в Confluence. Не исчезла и граница ролей: бизнес-требования, архитектура, спецификации и код закреплены за ролями, как и раньше. Граница аналитик/архитектор переехала в спецификации, но не растворилась.

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

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

AI не заменил архитектора. Он убрал дефицит производства артефактов и сделал дефицитом инженерное суждение.

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

Поделитесь в комментариях, как у вас устроено ревью агентного выхода?