С развитием AI-агентов главный дефицит смещается: кодить и тестировать машины уже помогают, а вот проектирование системы по-прежнему остаётся узким местом, которое требует человеческого мышления.
Вопрос не в том, куда направить силы разработчика в эпоху AI: писать код или тестировать. Оба навыка никуда не исчезают, однако именно здесь агенты уже сейчас заметно ускоряют команду. Настоящее узкое место лежит на более раннем этапе — проектировании системы. Это одна из самых когнитивно тяжёлых частей инженерной работы. Прежде чем появится первая строка кода, придётся дать ответы на десятки вопросов: где проходят границы системы, кто пользователи, внешние акторы и сервисы, какие компоненты нужны и за что каждый отвечает, как они общаются — синхронно или асинхронно, какие данные ходят между ними, какие API и event-контракты надо зафиксировать, где и как хранятся данные, какие есть интеграции, требования к нагрузке, отказоустойчивости, безопасности и параллелизму, что нельзя нарушать и как понять, что изменение действительно готово. Чем точнее команда отвечает на эти вопросы до реализации, тем дешевле обходятся ошибки и переделки позже. Хорошее проектирование не даёт гарантий идеального результата, но создаёт для него основу.
Беда традиционной документации в том, что она часто живёт отдельно от разработки: диаграммы — в одном инструменте, решения — в wiki, контракты — в другой системе, а реализация — в репозиториях. В итоге и инженеру, и AI-агенту приходится собирать контекст вручную. Viaduct предлагает сделать архитектурную модель центральной точкой работы: не статичной схемой «для отчёта», а живым представлением контекста, контейнеров, компонентов, документации, последовательностей взаимодействий и API-контрактов. В модели описываются C4-уровни, потоки данных, последовательности вызовов, ER-модели, а Markdown-описания и контракты привязываются прямо к элементам, к которым относятся. Можно подключить дизайн-систему из Figma, чтобы получить базовые токены UI-проекта, а интеграцию Figma к UI-компонентам — привязать каждый элемент к конкретной ноде.
Как это работает на практике. Сначала разработчик или архитектор проектирует изменение от начала до конца: описывает, какие части системы затрагиваются (тут помогают все слои C4 в зависимости от глубины проработки), добавляет или уточняет сервисы, компоненты, связи и потоки данных. Грамотно прописанный поток данных в 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.
Загрузка...
