Solution Architect в эпоху AI-агентов: как меняется роль и почему это важно

Когда три четверти нового кода крупнейшей IT-компании планеты пишет машина, это не просто цифра для слайда - это сигнал, что производственный процесс разработки изменился структурно.

Цифры, которые задают контекст

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

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

Вывод прямой: генерация кода подешевела, контроль за ним - нет.

Codebase cognitive debt: новый термин для старой боли

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

Узкое место сместилось. Раньше тормозило написание спецификаций и кода. Теперь тормозит постановка задачи AI (intent) и контроль генерации (review): что именно должна делать система, в каких границах, и кто проверяет, что агент сделал именно это.

Код производится быстрее, чем кто-либо успевает подтвердить его соответствие требованиям.

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

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

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

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

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

Три варианта адаптации в 2025-2026

По описанию Соболекова, перед архитектором стояли три пути:

• Остаться автором диаграмм и полагаться на ручное ревью постфактум - с фрагментарным участием.
• Уйти в vibe coding без промежуточной спецификации.
• Стать автором исполняемой спецификации, которую агент выполняет, а человек проверяет.

Третий путь - это то, что исследователь OpenAI Шон Гроув назвал spec-driven подходом в докладе «The New Code» на AI Engineer World’s Fair 2025. Его аргументы: промптинг уступает место спецификациям, фиксация спецификаций в письменном виде делает их полезными для LLM и помогает людям договориться, а спецификации важнее кода - слишком много нюансов теряется, если остаётся только код.

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

Spec-driven development: три уровня

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

• spec-first - спецификация пишется до кода и после генерации не обязана жить.
• spec-anchored - спецификация живёт вместе с кодом и остаётся точкой синхронизации при каждом изменении.
• spec-as-source - код генерируется из спецификации и вручную не правится.

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

От автора диаграмм к инженеру контекста

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

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

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

Что это значит

Если ты архитектор, тимлид или продакт - ситуация простая: скорость генерации кода уже опередила скорость его осмысления. Это не абстрактная угроза, это то, что Thoughtworks назвал codebase cognitive debt, а 38% разработчиков уже чувствуют на себе в виде более тяжёлого ревью.

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

Источник: Алексей Соболеков, Habr, 13 июля 2025 - https://habr.com/ru/articles/1058748/

FAQ

Что такое codebase cognitive debt? Термин из Technology Radar vol. 34 (Thoughtworks, апрель 2026) - разрыв в понимании между командой и кодовой базой, который накапливается по мере того, как AI генерирует всё больше кода, а люди не успевают его осмыслить.

Чем spec-anchored отличается от spec-first? Spec-first - спецификация пишется до кода и после не нужна. Spec-anchored - спецификация живёт синхронно с кодом и обновляется при каждом изменении. Для долгоживущих систем нужен второй вариант.

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