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