Да, все так. Мой разбор скорее про ситуации, когда вайбкод проект разрастается до больших масштабов, и где сложно уже находить различные точки взаимодействия, проблемы и т.д. В общем ровно все те проблемы, которые появляются у растущего стартапа, да и когда команд становится уже несколько и каждый начинает перерабатывать и поддерживать свою доменную область.
Согласен с экспериментом — ровно так мы и сделали, репозитории уже лежат в одной папке. Проблема не в этом, а в результате: граф зависимостей покажет импорты, но не покажет, что Python-воркер пишет в базу Java-сервиса. А UML — тупиковый артефакт: каждый прогон перегенерация с новой дисперсией, и картинку никто не читает как данные. Даже если сделать эту схему в PlantUML с довольно большим размером, то агент все-равно будет дисперсно выдавать при каждой генерации. Да и для человека огромные схемы нарисованные в PlantUML крайне не возможно воспринимать. А модель в Viaduct — рабочая память агентов и интерактив для человека, а не рисунок. Да и кроме схем, там так же лежат и контракты, и документация и потоки данных, сквозь которые можно посмотреть как работает бизнес функционал.
доступ к репозиторию у него был, ему в таком случае придется пойти, просканить весь репозиторий, потратить кучу токенов, сделать какие-то выводы. Хотя если бы уже был весь контекст в проекте по этому репозиторию, то ему значительно дешевле было бы пойти и исправить точечно то что нужно
Согласен — про идемпотентность вероятностного вывода не поспоришь, речь скорее про снижение дисперсии. А «контекст агент достаёт сам» ровно поэтому и не работает: сам процесс доставания вероятностный (какие файлы открыл, в каком порядке, какая модель). Модель в Viaduct это снимает — она фиксирована между прогонами и лежит между репозиториями, а не внутри кода, поэтому анализом кода её и не получить. Про «документировать» — так и хочется, только документация гниёт, а модель агент поддерживает сам. И да, всё зависит от глубины проработки человека — вкладываться лучше один раз в структуру, а не в каждый промпт :)
diff'ы magic flow у меня уже были заготовлены, так что статусы валидности и инвалидности потоков было не сложно сейчас добавить. Спасибо за хороший поинт. Я добавил валидацию потоков.
А насчет принятия новой версии потока - кажется тут зависит от слоя на котором он находится. Если, допустим, поток находится на контекстном слое, то его может провалидировать и продуктовая часть команды, если же спускаемся до сервисов, то ответственный за интеграцию, или коллективно командами участвующих сервисов, но все-равно придется принять кому-то волевое решение, что оно работает так. Но если уж есть архитектор, который прорабатывал данную интеграцию, то и он. Все будет зависеть от слоя, на котором находится диаграмма, а так же практик принятых в отдельно взятых командах.
Очень хорошая мысль. Я часто думаю насчет того, как вообще поддерживать актуальность связей, потоков, сервисов и вообще всего ландшафта. С одной стороны можно актуализацию проводить после релиза контракта, зашить в CI актуализацию документации, потоков, контрактов и связей. С другой стороны хочется иметь набор версий каждой связанности и при изменении контрактов действительно подсвечивать валидацию определенного magic flow. К единому мнению еще не пришел.
C4 всё же больше про послойное описание архитектуры, чем непосредственно про инфраструктуру. Но если смотреть на жизненный цикл каждого элемента, неизбежно возникает вопрос: как поддерживать всю эту документацию в актуальном состоянии?
С одной стороны, хочется уже на старте иметь понятный и полный набор моделей, связей и структур. С другой — важно, чтобы это «безобразие» не устаревало через несколько месяцев.
С первой частью обычно всё относительно понятно. Со второй часто возникают проблемы:
Нет централизованного процесса поддержки документации. Как ни унифицируй подходы, со временем команды всё равно начинают использовать инструменты и форматы, которые удобнее именно им.
Разработчикам и аналитикам естественно держать документацию рядом с кодом, в репозитории, и обновлять её через привычный процесс review и merge request’ов.
Не определён источник истины. Что считать реальностью: документацию, где были зафиксированы договорённости, или фактическую реализацию сервиса?
Для себя я пришёл к тому, что источником истины должны быть именно зафиксированные договорённости. Желательно, чтобы документация была трассируема до требований, реализации и тестов — и обратно. Тогда второй и третий пункты во многом решаются сами собой: документация становится частью инженерного процесса, а не побочным артефактом.
Кроме того, при современных AI-подходах документация может быть не только описанием уже реализованной системы. На её основе можно генерировать контракты, интерфейсы, каркасы сервисов и часть бизнес-логики.
Кстати, в моем сервисе для авторизованных пользователей доступен MCP-сервер: например, в Cursor можно получить весь необходимый контекст и при необходимости редактировать его прямо из рабочей среды.
да, как только сервис будет наполнен и отлажен, сделаю публичным на github. Но пока есть идеи сделать плагин для VS Code или уйти в standalone...но это скорее идеи, чем что-то масштабируемое на долгий срок
Information
Rating
1,418-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Да, все так. Мой разбор скорее про ситуации, когда вайбкод проект разрастается до больших масштабов, и где сложно уже находить различные точки взаимодействия, проблемы и т.д. В общем ровно все те проблемы, которые появляются у растущего стартапа, да и когда команд становится уже несколько и каждый начинает перерабатывать и поддерживать свою доменную область.
Согласен с экспериментом — ровно так мы и сделали, репозитории уже лежат в одной папке. Проблема не в этом, а в результате: граф зависимостей покажет импорты, но не покажет, что Python-воркер пишет в базу Java-сервиса. А UML — тупиковый артефакт: каждый прогон перегенерация с новой дисперсией, и картинку никто не читает как данные. Даже если сделать эту схему в PlantUML с довольно большим размером, то агент все-равно будет дисперсно выдавать при каждой генерации. Да и для человека огромные схемы нарисованные в PlantUML крайне не возможно воспринимать.
А модель в Viaduct — рабочая память агентов и интерактив для человека, а не рисунок. Да и кроме схем, там так же лежат и контракты, и документация и потоки данных, сквозь которые можно посмотреть как работает бизнес функционал.
доступ к репозиторию у него был, ему в таком случае придется пойти, просканить весь репозиторий, потратить кучу токенов, сделать какие-то выводы. Хотя если бы уже был весь контекст в проекте по этому репозиторию, то ему значительно дешевле было бы пойти и исправить точечно то что нужно
Согласен — про идемпотентность вероятностного вывода не поспоришь, речь скорее про снижение дисперсии. А «контекст агент достаёт сам» ровно поэтому и не работает: сам процесс доставания вероятностный (какие файлы открыл, в каком порядке, какая модель). Модель в Viaduct это снимает — она фиксирована между прогонами и лежит между репозиториями, а не внутри кода, поэтому анализом кода её и не получить. Про «документировать» — так и хочется, только документация гниёт, а модель агент поддерживает сам. И да, всё зависит от глубины проработки человека — вкладываться лучше один раз в структуру, а не в каждый промпт :)
а как без качественного контекста всей экосистемы будет обеспечиваться идемпотентность результата?
Как и обещал https://github.com/quietgridlabs/viaduct
diff'ы magic flow у меня уже были заготовлены, так что статусы валидности и инвалидности потоков было не сложно сейчас добавить. Спасибо за хороший поинт. Я добавил валидацию потоков.
А насчет принятия новой версии потока - кажется тут зависит от слоя на котором он находится.
Если, допустим, поток находится на контекстном слое, то его может провалидировать и продуктовая часть команды, если же спускаемся до сервисов, то ответственный за интеграцию, или коллективно командами участвующих сервисов, но все-равно придется принять кому-то волевое решение, что оно работает так.
Но если уж есть архитектор, который прорабатывал данную интеграцию, то и он.
Все будет зависеть от слоя, на котором находится диаграмма, а так же практик принятых в отдельно взятых командах.
Очень хорошая мысль. Я часто думаю насчет того, как вообще поддерживать актуальность связей, потоков, сервисов и вообще всего ландшафта. С одной стороны можно актуализацию проводить после релиза контракта, зашить в CI актуализацию документации, потоков, контрактов и связей.
С другой стороны хочется иметь набор версий каждой связанности и при изменении контрактов действительно подсвечивать валидацию определенного magic flow.
К единому мнению еще не пришел.
Делаю похожий на него инструмент, но, как говорится с блекджеком. И точно не за десятки тысяч долларов для enterprise :)
Viaduct
На самом деле вы оба правы.
C4 всё же больше про послойное описание архитектуры, чем непосредственно про инфраструктуру. Но если смотреть на жизненный цикл каждого элемента, неизбежно возникает вопрос: как поддерживать всю эту документацию в актуальном состоянии?
С одной стороны, хочется уже на старте иметь понятный и полный набор моделей, связей и структур. С другой — важно, чтобы это «безобразие» не устаревало через несколько месяцев.
С первой частью обычно всё относительно понятно. Со второй часто возникают проблемы:
Нет централизованного процесса поддержки документации. Как ни унифицируй подходы, со временем команды всё равно начинают использовать инструменты и форматы, которые удобнее именно им.
Разработчикам и аналитикам естественно держать документацию рядом с кодом, в репозитории, и обновлять её через привычный процесс review и merge request’ов.
Не определён источник истины. Что считать реальностью: документацию, где были зафиксированы договорённости, или фактическую реализацию сервиса?
Для себя я пришёл к тому, что источником истины должны быть именно зафиксированные договорённости. Желательно, чтобы документация была трассируема до требований, реализации и тестов — и обратно. Тогда второй и третий пункты во многом решаются сами собой: документация становится частью инженерного процесса, а не побочным артефактом.
Кроме того, при современных AI-подходах документация может быть не только описанием уже реализованной системы. На её основе можно генерировать контракты, интерфейсы, каркасы сервисов и часть бизнес-логики.
Кстати, в моем сервисе для авторизованных пользователей доступен MCP-сервер: например, в Cursor можно получить весь необходимый контекст и при необходимости редактировать его прямо из рабочей среды.
да, как только сервис будет наполнен и отлажен, сделаю публичным на github. Но пока есть идеи сделать плагин для VS Code или уйти в standalone...но это скорее идеи, чем что-то масштабируемое на долгий срок