Введение

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

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

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

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

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

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

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

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

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

В текущем проекте часть проектирования уже выполняют 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% инициатив. Один архитектор вел от 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 — спецификация, живущая синхронно с кодом.

Spec-anchored закрывает требования только на уровне одной фичи. Продуктовый контекст — границы, модель данных, роли — он предполагает известным. Где этот контекст хранится, остается за скобками.

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

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

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

Архитектор перестает быть поставщиком одного артефакта среди многих. Он задает пространство, в котором работают агенты и команды, границы (ограничения, правила применения) и проверяет их выход на соответствие этим границам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Агентный подход применим не везде. Он окупается при постоянном потоке инициатив, параллельных командах и внедренном агентном процессе с барьером проверки перед разработкой. Для одиночного проекта с одной командой и редкими изменениями архитектуры классическая модель с точечными ревью остается рабочей. Постоянный контроль агентного выхода оправдан там, где объем генерируемых артефактов превышает пропускную способность точечной проверки. Даже тогда решения агентов имеет смысл перепроверять выборочно и постфактум — это отдельный слой надзора.

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

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

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

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

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

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

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

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

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

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