Почему AI-агенту недостаточно репозитория: архитектура как общее представление системы

[CrushBy]

Собственно, Вы описали примерно ту идею, на которой построен lsFusion, только применительно к бизнес-приложениям.

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

Поэтому AI действительно проще работать с таким кодом: вместо сотен файлов с технической инфраструктурой у него есть достаточно плоское высокоуровневое описание предметной области. Хотя вопрос «почему именно так» это, конечно, полностью не решает.

Тут другой интересный вопрос. Ваш граф предполагается делать первичным источником, из которого генерируется Go-код, или извлекать его из уже существующего кода? В первом случае непонятно, как потом мержить ручные изменения, а во втором в граф неизбежно попадут случайные детали реализации. Или предполагается какой-то двусторонний вариант?

[gorundebug]

В текущей реализации используется двусторонний вариант, и он уже работает для той структуры, которая задаётся фреймворком.

Из графа можно сгенерировать Go-сервис(ы). Если затем разработчик вручную изменит в коде поддерживаемую фреймворком структуру, её можно извлечь обратно и загрузить в дизайнер.

При этом речь не идёт о восстановлении всей программы или произвольной бизнес-логики. Сейчас извлекаются узлы графа, связи между ними, семантика вызовов и частично информация о контрактах. Кастомный код внутри узлов остаётся обычным Go-кодом и обратно в граф не преобразуется.

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

Поэтому это не полный round-trip для Go-кода, а двусторонняя синхронизация той части архитектурной структуры, которая выражена через примитивы фреймворка. Случайные детали реализации при таком извлечении в граф попадать не должны, поскольку анализируется не произвольный код, а только известные фреймворку конструкции.

[CrushBy]

Понятно, спасибо. То есть по факту получается что-то вроде embedded DSL внутри Go: фреймворк задаёт ограниченный набор архитектурных примитивов, и round-trip работает именно в пределах этого набора. Вполне разумная граница.

Основное ограничение тогда перемещается из структуры в семантику. Граф отвечает на вопрос «как устроена система», а описание того, «что должен делать узел», хранится отдельно. Если разработчик вручную изменит бизнес-логику внутри Go-кода, структура успешно загрузится обратно в дизайнер, но архитектурное описание поведения может остаться прежним. То есть два источника истины всё равно остаются, просто уже на уровне смысла.

В lsFusion значительная часть ответа на вопрос «что делает узел» также является исполняемой декларативной моделью: свойства задают вычисления и ограничения, действия — изменение состояния, а зависимости между ними строит сама платформа. Императивный Java-код остаётся в основном для низкоуровневых вещей и интеграций. Поэтому рассинхронизация между описанием поведения и реализацией возникает реже.

В любом случае теперь подход понятен. Для описания и двусторонней синхронизации именно архитектурной структуры такое ограничение выглядит логичным. Спасибо за подробное объяснение.

[gorundebug]

Да, абсолютно верно. В некотором смысле так было всегда: либо мы сначала изменяем описание системы и затем приводим реализацию в соответствие с ним, либо меняем код, после чего актуализируем описание.

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

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

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

Более того, агент может использовать этот слой не только как контекст для изменения кода. Он может предлагать или вносить изменения и в саму архитектуру. Поскольку архитектурная модель формализована и валидируется, такие изменения можно проверить до генерации или модификации реализации.

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