Можно ли описать архитектуру на Python, а получить работающий каркас сервиса на Go, C++, Rust или TypeScript? Причём так, чтобы схема не становилась отдельной документацией, которую все забывают обновлять.

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

Последнее время я почти не пишу код руками — значительную часть реализации берут на себя AI-агенты. Но работы меньше не стало: теперь нужно задавать ограничения, проверять архитектуру и понимать результат, не перечитывая тысячи сгенерированных строк. Я попробовал сделать архитектурный граф общей моделью для человека, агента и генератора кода. Из одного графа получил сервисы на Go, Python, C++ и Rust, а затем сравнил их с прямыми реализациями того же HTTP → gRPC сценария. Главный вопрос эксперимента: какова runtime-плата за систему, которую проще понимать, изменять и наблюдать?

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

В статье я рассматриваю другую возможность: формальное архитектурное представление между намерением и кодом. Типизированный исполняемый граф может одновременно задавать границы для AI, валидировать архитектурные изменения, генерировать сервис и локальные SDD-задачи, а в runtime служить картой наблюдаемости. Это инженерная гипотеза о том, каким может стать интерфейс совместной работы человека и AI.