Куда инвестировать усилия разработчику в эпоху AI?
В написание кода? В тестирование? Безусловно, эти навыки остаются важными. Но всё чаще именно они становятся областью, где AI-агенты могут заметно ускорить работу команды.
Настоящее узкое место находится раньше — на этапе проектирования.
Проектирование системы — одна из самых когнитивно сложных частей инженерной работы. До того как появится первая строка кода, нужно ответить на десятки вопросов:
Где проходят границы системы?
Какие есть пользователи, внешние акторы и сервисы?
Какие компоненты понадобятся и за что каждый из них отвечает?
Как они взаимодействуют: синхронно или асинхронно?
Какие данные передаются между ними?
Какие API и event-контракты необходимо зафиксировать?
Где и как хранятся данные?
Какие есть интеграции, требования к нагрузке, отказоустойчивости, безопасности и параллелизму?
Какие ограничения нельзя нарушать?
Как понять, что изменение действительно готово?
Чем точнее команда отвечает на эти вопросы до реализации, тем ниже стоимость ошибок и переделок позднее. Хорошее проектирование не гарантирует идеальный результат, но создаёт для него необходимую основу.
От документа к исполнимому плану
Проблема традиционной документации в том, что она часто живёт отдельно от разработки: диаграммы лежат в одном инструменте, решения — в wiki, контракты — в другой системе, а фактическая реализация — в репозиториях. В результате и инженеру, и AI-агенту приходится собирать контекст вручную.
Viaduct предлагает сделать архитектурную модель центральной точкой работы над системой: не статичной схемой «для отчёта», а живым представлением контекста, контейнеров, компонентов, документации, последовательностей взаимодействий и API-контрактов. В модели можно описывать C4-уровни, потоки данных, последовательности вызовов, ER-модели и привязывать Markdown-описания и контракты непосредственно к элементам, к которым они относятся, а так же можно интегрировать Figma к UI компонентам, привязать каждый элемент к конкретной Ноде.
Подключив дизайн систему проект получает все необходимые базовые токены из UI проекта.
Так документация становится не приложением к коду, а структурированным контекстом, через который можно понимать и изменять систему.
Как это работает
Разработчик или архитектор сначала проектирует изменение от начала до конца:
Описывает, какие части системы затрагиваются. Здесь помогают все слои С4 в зависимости от глубины проработки системы и ее элементов.
Добавляет или уточняет сервисы, компоненты, связи и потоки данных. Грамотно прописанный поток данных в Magic Flow позволяет агенту лучше всего понять где какая конкретная интеграция и что на каждом шаге происходит.
Пример Magic Flow просмотра прогноза погоды Фиксирует взаимодействия между участниками. Для презентации между командами можно проиграть нужный magic flow, чтобы убедиться, что все договоренности корректны.
Пример проигрывания Magic Flow Определяет контракты, ограничения, требования к хранению и интеграциям. Можно описать любой контракт (Rest, GRPC), топики в Kafka или очереди в RabbitMQ.
Описание Rest GET контракта прогноза погоды Формулирует критерии приёмки. Для Change set лучше стараться хорошо описать Acceptance Criteria, как обычно в задаче на разработку.
Экран заполнения Change set Создаёт Change Set — набор согласованных изменений в архитектурной модели. В нем указывается версия в рамках которой мы хотим реализовать. Описываем кратко, что нужно сделать, какие-либо ограничения или пожелания, а так же набор Acceptance Criteria. И после создания копируем код, который нужно вставить агенту с подключенным MCP.
Экран уже закоммиченного Change set
После этого Change Set становится понятным планом работы для AI-агента: что нужно реализовать, почему это нужно сделать, какие сервисы затронуты, какие контракты обязаны сохраниться и по каким критериям результат будет принят.
Почему это важно
AI хорошо справляется с реализацией, когда задача имеет ясные границы. Но если дать агенту расплывчатое «добавь фичу», он будет угадывать:
какую часть системы менять;
какой контракт считать источником истины;
какие зависимости затронет изменение;
что нельзя сломать;
какой компромисс между скоростью, масштабируемостью и сложностью допустим.
Качественная архитектурная модель устраняет значительную часть этого угадывания. Она превращает намерение команды в контекст, а контекст — в выполнимую задачу.
Именно поэтому правильная инвестиция для разработчика в эпоху AI — не отказ от программирования, а усиление инженерного мышления: декомпозиции, системного дизайна, моделирования данных, API-дизайна, формулирования ограничений и критериев приёмки.
Демо кликабельная модель: Weather forecaster
