AI-агент собирает рабочий модуль за минуты, а инженер тратит день на уточнение задачи и проверку результата. Написание кода перестало быть дефицитным ресурсом. Главное ограничение разработки теперь в другом: в проектировании системы, её границ, контрактов, потоков данных и критериев приёмки.
Игорь Головко, основатель инструмента архитектурного моделирования Viaduct, формулирует это так: качественная архитектурная модель даёт инженеру и AI-агенту одинаковое понимание границ системы, контрактов, потоков данных и критериев приёмки. Пока общего описания нет, агент работает с противоречивыми или неполными требованиями, и результат получается хрупким: он проходит проверку на одном сценарии и разваливается на соседнем.
Программирование при этом не отменяется. Меняется доля времени: меньше ручного набора кода, больше проектирования, постановки ограничений и приёмки результата. Практическая форма этого сдвига - Change Set, согласованный набор изменений с Acceptance Criteria, который через MCP уходит AI-агенту как исполнимый план работы.
Почему код перестал быть узким местом: смена парадигмы в AI-разработке
Сдвиг видно по тому, где команды теряют часы. Генерация кода стала быстрой операцией. Согласование требований, разбор неоднозначностей и проверка сгенерированного занимают всё больше времени. Механика этого смещения разобрана в статье о том, как AI-ассистенты переносят узкие места на ревью и тестирование.
Что именно берут на себя AI-агенты, а что остаётся человеку
Агент уверенно закрывает задачи с чётким заданием: реализовать метод по спецификации, написать тесты для описанного поведения, сгенерировать клиент по контракту, поправить обработку ошибок в известном модуле. Он быстро перебирает варианты и не устаёт от рутины.
Границы системы агент не определяет. Он не решает, где заканчивается один сервис и начинается другой, кому принадлежат данные заказа, что делать при недоступности внешнего API и какая задержка считается допустимой. Если этих решений нет в явном виде, агент достраивает их сам по локальному контексту файла. Так появляется код, который корректен внутри функции и неверен в масштабе системы.
Разделение ответственности выглядит так:
- человек задаёт границы, контракты, модель данных и критерии приёмки;
- человек выбирает архитектурный стиль и технологический стек;
- агент вносит изменения внутри заданных границ;
- человек проверяет соответствие результата модели и принимает работу.
Без первого пункта остальные теряют смысл: проверять нечего, потому что эталон не зафиксирован.
Почему «просто писать код» больше не конкурентное преимущество
Скорость набора кода перестала быть дефицитным ресурсом. Дефицит сместился к декомпозиции, системному дизайну и формулированию ограничений. Головко описывает инвестицию разработчика в эпоху AI именно так: усиление навыков декомпозиции, системного дизайна и формулирования ограничений, а не отказ от программирования.
Понимание кода при этом не слабеет, а растёт в цене. Чтобы поставить агенту задачу и оценить результат, нужно читать чужой и сгенерированный код, видеть лишнюю сложность, замечать неверные допущения и понимать, чем обернётся конкретное решение через полгода. Архитектурные решения остаются зоной ответственности человека, и чем больше кода генерирует агент, тем выше требования к тому, кто его принимает.
Что такое архитектурная модель и зачем она AI-агенту
Архитектурная модель это формализованное описание системы: что в неё входит, с чем она общается, как двигаются данные и по каким условиям изменение считается готовым. Она работает как единый источник правды для инженера и для агента.
Ключевое отличие от документации «для галочки»: модель используют в работе. Задача агенту формулируется через её элементы, а не через свободный текст в тикете. Viaduct привязывает к элементам модели Markdown-документацию и Figma-компоненты, поэтому контекст живёт рядом с описанием системы и не расползается по разным хранилищам.
Есть и обратная сторона: чем больше контекста приходится держать в актуальном состоянии, тем дороже сопровождение. Архитектурная энтропия остаётся главным тормозом разработки, и модель помогает только тогда, когда её обновляют вместе с кодом.
Границы системы, контракты и потоки данных как язык общения с агентом
Три элемента модели закрывают большую часть неоднозначностей при постановке задачи.
Границы отвечают на вопрос, что входит в систему, а что остаётся снаружи. Контракты фиксируют интерфейсы: методы, форматы, коды ошибок, схемы сообщений. Потоки данных показывают, откуда приходят данные, где преобразуются и куда попадают.
Логическая иллюстрация. Если контракт между сервисом заказов и сервисом уведомлений не описан, агент может выбрать синхронный HTTP-вызов там, где ожидается событие. Формально код заработает, но сервис заказов начнёт зависеть от доступности сервиса уведомлений, а повторная отправка приведёт к дублю сообщений. Ошибка не в коде, а в отсутствующем решении.
Критерии приёмки: как превратить ожидания в проверяемые условия
Acceptance Criteria описывают условия, при которых изменение считается завершённым. Их пишут так, чтобы результат можно было проверить, а не обсудить.
Логический пример для эндпоинта создания заказа: повторный запрос с тем же ключом идемпотентности возвращает тот же ответ и не создаёт второй заказ; при недоступности сервиса оплаты заказ переходит в состояние ожидания и не теряется; лог содержит идентификатор запроса и код ошибки. Такие формулировки оставляют минимум места для трактовок и дают агенту готовый чек-лист самопроверки.
Размытые критерии вроде «работает быстро» или «корректно обрабатывает ошибки» проверке не поддаются. Агент закрывает по ним задачу формально, а на ревью выясняется, что половина сценариев не покрыта.
Инструменты архитектурного моделирования: C4, Magic Flow, ER-модели и API-контракты
Viaduct описывает систему через несколько взаимодополняющих нотаций: C4-уровни, Magic Flow, ER-модели и API-контракты. Каждая закрывает свой срез, вместе они дают агенту контекст, которого не хватает в одном файле с кодом.
C4-уровни: от контекста до кода без потери смысла
C4 задаёт четыре уровня детализации: контекст, контейнеры, компоненты, код. Контекст показывает систему и внешние сущности, с которыми она взаимодействует. Контейнеры описывают приложения, сервисы и хранилища. Компоненты раскрывают внутреннее устройство контейнера. Код детализирует реализацию.
Для постановки задачи агенту чаще всего достаточно контекста и контейнеров: они задают границы и запрещают агенту трогать лишнее. Уровень кода нужен точечно, когда изменение затрагивает конкретный модуль.
Magic Flow и ER-модели: как показать данные в движении и в покое
Magic Flow показывает, как данные перемещаются между компонентами: какой сервис что принимает, преобразует и передаёт дальше. ER-модели описывают структуру хранения: сущности, атрибуты, связи и кардинальность.
Вместе они отвечают на вопросы, которые агент иначе решает наугад. Нужна ли отдельная таблица для истории статусов или достаточно поля в основной? Кто владелец сущности клиента: сервис профиля или биллинг? Что происходит с заказом при удалении пользователя? Ответы в модели означают, что агенту не придётся выбирать их самостоятельно.
API-контракты REST, gRPC, Kafka, RabbitMQ: единый язык для сервисов и агентов
REST и gRPC описывают синхронные взаимодействия: методы, схемы запросов и ответов, коды ошибок. Kafka и RabbitMQ покрывают асинхронную часть: топики, очереди, форматы сообщений, гарантии доставки.
Разные типы контрактов уживаются в одной модели, потому что описывают разные способы общения. Синхронный вызов подходит для запроса данных по требованию, событие подходит для уведомления других сервисов об уже случившемся факте. Агент, получивший контракты, генерирует совместимый код: те же поля, те же коды, та же схема сообщения.
Важная оговорка: Viaduct в описании позиционируется как инструмент моделирования, а не как генератор кода. Данных о метриках его эффективности, стоимости или сравнении с альтернативами в открытых материалах нет.
Change Set и MCP: как архитектура превращается в задание для AI-агента
Change Set это согласованный набор изменений с Acceptance Criteria, который через MCP передаётся AI-агенту как исполнимый план работы. Внутри него лежит не пожелание, а структурированное описание: что меняется, в каких границах, по каким контрактам и по каким условиям работа считается принятой.
Почему Change Set снижает риск неверной реализации
Обычный тикет допускает разные прочтения: он не фиксирует границы изменений и не задаёт критериев готовности. Change Set снимает эту свободу. Агент видит, какие модули затронуты, какие контракты обязаны остаться неизменными, какие данные нельзя терять и что именно проверяется на приёмке.
Эффект не в том, что агент перестаёт ошибаться. Эффект в том, что ошибка становится видна на этапе проверки критериев, а не через неделю в продакшене. Количество итераций сокращается за счёт однозначности постановки.
MCP как канал передачи: что это даёт на практике
MCP (Model Context Protocol) передаёт агенту структурированный контекст. В сценарии Viaduct через него идёт Change Set: агент получает не разрозненные файлы и переписку, а целостное описание изменения вместе с моделью.
MCP это развивающийся открытый стандарт, и его поддержка различается в разных инструментах. Практический пример того, как выглядит работа с MCP на стороне сервисов: ядро schema-mcp-core занимает около 2200 строк, а сервер поверх него 66 строк. Пять серверов живут отдельными репозиториями, и без общего ядра каждый нёс бы свою копию одного и того же кода, так что правка в механике доступа чинила бы один репозиторий и оставляла четыре сломанными.
У ядра есть готовый набор инструментов MCP: поиск, описание, вызов, кабинеты. Каждый метод помечен классом доступа read, write или destructive. Методы write и destructive требуют явного согласия на стороне вызова: ядро само в сеть не ходит, ключи в репозитории не хранит и без подтверждения в сервис не пишет. Для агентной разработки это принципиально. Агент с доступом к продакшен-системе без такого разделения уровней превращается в источник необратимых изменений.
Какие навыки развивать разработчику в эпоху AI
Список короткий, но требует практики: декомпозиция, системный дизайн, формулирование ограничений. Тренируются они на реальных задачах, а не на курсах по промптам.
Декомпозиция: как разбить систему на части, которые поймёт агент
Декомпозиция это выделение компонентов, их ответственностей и связей. Слишком крупный блок агент закрывает непредсказуемо, слишком мелкий превращает Change Set в сотню несвязанных задач. Ориентир такой: одна порция изменений должна проверяться одним набором Acceptance Criteria и затрагивать не больше одного-двух компонентов.
Логический пример: задача «сделать авторизацию» слишком широка. Внутри неё выбор провайдера, схема хранения сессий, разграничение ролей, обработка истечения токена. Агент закроет её своим способом, и способ этот может не совпасть с моделью. Пять отдельных Change Set с критериями приёмки дают предсказуемый результат.
Системный дизайн: мышление на уровне взаимодействия компонентов
Системный дизайн включает выбор архитектурного стиля, определение границ, проектирование взаимодействий, оценку отказоустойчивости. Это то, что агент за человека не сделает: он работает внутри поставленной рамки и не ставит под сомнение саму рамку.
C4-уровни помогают удерживать мышление в порядке: сначала контекст и внешние зависимости, потом контейнеры, потом компоненты. Такой порядок не даёт уйти в детали раньше времени.
Формулирование ограничений: как не дать агенту «уйти в разнос»
Ограничения описывают то, что нужно сделать, и то, чего делать нельзя: не менять публичные контракты, не добавлять новые зависимости без согласования, не трогать модуль оплаты, уложиться в заданную задержку. Чем конкретнее ограничения, тем предсказуемее результат.
Ограничения и Acceptance Criteria работают в паре. Первые сужают пространство решений, вторые задают проверяемую планку. Агент, у которого есть и то и другое, реже выходит за пределы задачи.
Ограничения и риски: где архитектурное моделирование не спасёт
Подход требует дисциплины и времени. Модель устаревает за пару недель, если её не обновлять вместе с кодом, а поддержание актуальности никто не делает автоматически. Команда, у которой нет привычки описывать систему, получит от модели только дополнительную работу.
Когда модель становится оверхедом
Для прототипа или небольшого сервиса с одним разработчиком детальное описание всех уровней замедлит работу. Ориентиры, по которым стоит решать:
- частота изменений: редкие правки в стабильном модуле не требуют полной модели;
- число участников: один разработчик держит контекст в голове, пятерых агентов и людей уже нужно синхронизировать;
- сложность интеграций: один внешний API это одна история, пять контрактов с разными гарантиями доставки совсем другая;
- цена ошибки: в биллинге и платежах неоднозначность стоит дороже, чем в админке.
Технические риски: незрелость инструментов и зависимость от MCP
MCP молод, и его поддержка различается в разных инструментах. Viaduct это продукт с собственной дорожной картой, и она может меняться. Тезисы о том, что проектирование стало главным узким местом, пока опираются на позицию автора подхода, а не на измеренные данные: сравнений с альтернативами и метрик эффективности в открытом доступе нет.
Показательный пример уровня зрелости инфраструктурных инструментов в этой нише. verg, движок сведения инфраструктуры к желаемому состоянию на Rust, работает без хранения state-файлов между запусками: каждый прогон читает фактическое состояние системы и сходится к заданному. Он декларирует состояние в TOML с шаблонами Jinja2, проверяет конфигурацию до открытия SSH-соединения, отдаёт структурированные коды выхода и позволяет описывать собственные типы ресурсов. При этом документация прямо предупреждает: инструмент в активной разработке, между минорными версиями возможны ломающие изменения. Такой уровень зрелости стоит учитывать, прежде чем строить на подобном инструменте критичный процесс.
Как встроить подход в командные процессы: практические шаги
Начинать с полной перестройки процессов не нужно. Разумнее взять один участок и посмотреть, что изменится.
С чего начать: пилот на одном сервисе
- Выберите сервис с понятными границами и живыми изменениями.
- Опишите его в C4 на уровнях контекста и контейнеров, зафиксируйте контракты и модель данных.
- Сформулируйте один Change Set на небольшое изменение с тремя-пятью проверяемыми Acceptance Criteria.
- Передайте Change Set агенту через MCP и оцените результат.
- Сравните с обычной постановкой задачи: время до готового результата, число итераций, доля переделок.
Вспомогательные инструменты могут упростить отдельные шаги. schema-mcp-core даёт готовое ядро для MCP-серверов над API, verg закрывает сведение инфраструктуры к желаемому состоянию из скриптов и агентов. Оба полезны, оба не обязательны, и начинать стоит с малого. Дополнительный контекст о том, как выстроить предсказуемый рабочий процесс, есть в разборе Governance-стека для агентной разработки.
Роли в команде: кто отвечает за модель и Change Set
Целостность модели держит архитектор или тимлид: он решает спорные вопросы границ и следит, чтобы описание не расходилось с кодом. Разработчики формулируют Change Set и критерии приёмки, потому что именно они отвечают за результат в продакшене. Агент выполняет работу внутри заданных рамок.
Новых должностей вводить не нужно. Меняется акцент в обязанностях: часть времени, которая уходила на рутинный код, переходит в проектирование и приёмку.
Что это значит для будущего разработки
AI не отменяет разработчика, он переносит центр тяжести его работы. Там, где ценность измерялась скоростью набора кода, она измеряется способностью описать систему так, чтобы её понял и человек, и агент.
Практический вывод прост. Возьмите одну рабочую задачу на этой неделе и опишите её как Change Set: границы, контракты, потоки данных, проверяемые критерии. Даже если агент к проекту пока не подключён, такое описание покажет, сколько неоднозначностей вы обычно передаёте исполнителю. Дальше выбор небольшой: закрывать их в голове, как раньше, или зафиксировать в модели, которую переиспользуют и люди, и агенты.