AI меняет центр тяжести разработки

Viaduct

Куда инвестировать усилия разработчику в эпоху AI?

В написание кода? В тестирование? Безусловно, эти навыки остаются важными. Но всё чаще именно они становятся областью, где AI-агенты могут заметно ускорить работу команды.

Настоящее узкое место находится раньше — на этапе проектирования.

Проектирование системы — одна из самых когнитивно сложных частей инженерной работы. До того как появится первая строка кода, нужно ответить на десятки вопросов:

• Где проходят границы системы?

• Какие есть пользователи, внешние акторы и сервисы?

• Какие компоненты понадобятся и за что каждый из них отвечает?

• Как они взаимодействуют: синхронно или асинхронно?

• Какие данные передаются между ними?

• Какие API и event-контракты необходимо зафиксировать?

• Где и как хранятся данные?

• Какие есть интеграции, требования к нагрузке, отказоустойчивости, безопасности и параллелизму?

• Какие ограничения нельзя нарушать?

• Как понять, что изменение действительно готово?

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

От документа к исполнимому плану

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

Viaduct предлагает сделать архитектурную модель центральной точкой работы над системой: не статичной схемой «для отчёта», а живым представлением контекста, контейнеров, компонентов, документации, последовательностей взаимодействий и API-контрактов. В модели можно описывать C4-уровни, потоки данных, последовательности вызовов, ER-модели и привязывать Markdown-описания и контракты непосредственно к элементам, к которым они относятся, а так же можно интегрировать Figma к UI компонентам, привязать каждый элемент к конкретной Ноде.

Подключив дизайн систему проект получает все необходимые базовые токены из UI проекта.

Так документация становится не приложением к коду, а структурированным контекстом, через который можно понимать и изменять систему.

Как это работает

Разработчик или архитектор сначала проектирует изменение от начала до конца:

1. Описывает, какие части системы затрагиваются. Здесь помогают все слои С4 в зависимости от глубины проработки системы и ее элементов.

2. Добавляет или уточняет сервисы, компоненты, связи и потоки данных. Грамотно прописанный поток данных в Magic Flow позволяет агенту лучше всего понять где какая конкретная интеграция и что на каждом шаге происходит.

   

3. Фиксирует взаимодействия между участниками. Для презентации между командами можно проиграть нужный magic flow, чтобы убедиться, что все договоренности корректны.

   

4. Определяет контракты, ограничения, требования к хранению и интеграциям. Можно описать любой контракт (Rest, GRPC), топики в Kafka или очереди в RabbitMQ.

   

5. Формулирует критерии приёмки. Для Change set лучше стараться хорошо описать Acceptance Criteria, как обычно в задаче на разработку.

   

6. Создаёт Change Set — набор согласованных изменений в архитектурной модели. В нем указывается версия в рамках которой мы хотим реализовать. Описываем кратко, что нужно сделать, какие-либо ограничения или пожелания, а так же набор Acceptance Criteria. И после создания копируем код, который нужно вставить агенту с подключенным MCP.

   

После этого Change Set становится понятным планом работы для AI-агента: что нужно реализовать, почему это нужно сделать, какие сервисы затронуты, какие контракты обязаны сохраниться и по каким критериям результат будет принят.

Почему это важно

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

• какую часть системы менять;

• какой контракт считать источником истины;

• какие зависимости затронет изменение;

• что нельзя сломать;

• какой компромисс между скоростью, масштабируемостью и сложностью допустим.

Качественная архитектурная модель устраняет значительную часть этого угадывания. Она превращает намерение команды в контекст, а контекст — в выполнимую задачу.

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

Демо кликабельная модель: Weather forecaster