Последнее время я почти не пишу код руками: значительную часть реализации берут на себя AI-агенты. Но работы меньше не стало — она сместилась от написания к постановке задачи, определению ограничений, ревью и оценке результата. И чем быстрее агент производит код, тем острее становится вопрос: как проверить, что он построил именно ту систему, которая была задумана, не восстанавливая её устройство по тысячам сгенерированных строк?
В предыдущей статье я рассуждал о том, что между намерением разработчика и исходным кодом может быть полезен ещё один слой — формальное архитектурное представление системы. Не диаграмма для документации, а типизированный граф, который участвует в валидации, генерации кода и наблюдаемости.
За это время эксперимент стал заметно практичнее. Один и тот же граф теперь генерирует работающие сервисы на Go, Python, C++ и Rust. Более того, язык выбирается на уровне сервиса: например, Order Service можно сгенерировать на Go, а Inventory Service — на Rust, сохранив общий gRPC-контракт между ними.
Но главное изменение оказалось не в количестве поддерживаемых языков. Формальное архитектурное представление стало инструментом ревью. Вместо того чтобы восстанавливать архитектуру по десяткам тысяч строк кода, можно сравнить изменения на уровне графа.
