Comments 12
Начнётся реверс-инжиниринг всего навайбкоженного
После подтверждения MVP и выбрасывания кода в корзину не нужен реверс инжиниринг: контекста мало и всё свежее в головах, никто ещё не успел уволиться.
А вот когда MVP перезрел и уже 5 лет в поле тогда уже поздно. Тогда, да, платите по всем счетам сполна.
Из кода в легаси не ясно ровным счётом ничего
Я тут который месяц бьюсь за то чтобы выкинуть функционал из программы или хотя бы из сопровождения. И никак из кода не ясно что он не используется и почему так.
MCP для вот этого всего вам не нужен. Просто скажите агенту, где лежат все 4 репозитория и он все то же самое сделает.
а как без качественного контекста всей экосистемы будет обеспечиваться идемпотентность результата?
Идемпотентность для нейронок в целом неприменима, в силу вероятностного результата. Контекст агент достает сам, анализируя код. Если существует какой-то контекст вне системы, то его надо документировать.
Согласен — про идемпотентность вероятностного вывода не поспоришь, речь скорее про снижение дисперсии. А «контекст агент достаёт сам» ровно поэтому и не работает: сам процесс доставания вероятностный (какие файлы открыл, в каком порядке, какая модель). Модель в Viaduct это снимает — она фиксирована между прогонами и лежит между репозиториями, а не внутри кода, поэтому анализом кода её и не получить. Про «документировать» — так и хочется, только документация гниёт, а модель агент поддерживает сам. И да, всё зависит от глубины проработки человека — вкладываться лучше один раз в структуру, а не в каждый промпт :)
В порядке эксперимента, просто положите ваши репозитории в одну папочку и попросите какого-нибудь приличного агента, например Codex Sol, собрать схему зависимостей. Можно даже сразу в UML попросить.
Согласен с экспериментом — ровно так мы и сделали, репозитории уже лежат в одной папке. Проблема не в этом, а в результате: граф зависимостей покажет импорты, но не покажет, что Python-воркер пишет в базу Java-сервиса. А UML — тупиковый артефакт: каждый прогон перегенерация с новой дисперсией, и картинку никто не читает как данные. Даже если сделать эту схему в PlantUML с довольно большим размером, то агент все-равно будет дисперсно выдавать при каждой генерации. Да и для человека огромные схемы нарисованные в PlantUML крайне не возможно воспринимать.
А модель в Viaduct — рабочая память агентов и интерактив для человека, а не рисунок. Да и кроме схем, там так же лежат и контракты, и документация и потоки данных, сквозь которые можно посмотреть как работает бизнес функционал.
А агенту, который чинит очередной баг, этот контекст не достаётся вообще: он видит один репозиторий и свой промпт.
Проблема не в агенте, а в том, что вы не дали ему доступ к другим репозиториям (а могли дать).
доступ к репозиторию у него был, ему в таком случае придется пойти, просканить весь репозиторий, потратить кучу токенов, сделать какие-то выводы. Хотя если бы уже был весь контекст в проекте по этому репозиторию, то ему значительно дешевле было бы пойти и исправить точечно то что нужно
Почему сразу весь репозиторий? Ему хотя бы надо иметь к нему доступ, и иметь эту возможность - что-то там искать.
Больше контекста - в любом случае лучше и может дать лучший результат.
А иначе нет никакого смысла. Не дал контекста, не объяснил как надо - получай такой результат, какой получил, чудес не будет.
Про «MVP за вечер, а потом расхлёбывание» - в точку. Но есть нюанс: когда вайбкодит не разработчик, а владелец малого бизнеса, требования другие. Витрину-лендинг не надо переписывать на Java по канону - там цена архитектурной ошибки низкая, а время выхода важнее. Мы как раз делаем сервис, где сайт собирается в диалоге с ИИ (smart-ai24): человек описывает бизнес словами, система отдаёт готовые страницы. Для нетехнических людей это уже рабочий инструмент, а не игрушка. Ваш разбор скорее про следующий уровень зрелости.
Да, все так. Мой разбор скорее про ситуации, когда вайбкод проект разрастается до больших масштабов, и где сложно уже находить различные точки взаимодействия, проблемы и т.д. В общем ровно все те проблемы, которые появляются у растущего стартапа, да и когда команд становится уже несколько и каждый начинает перерабатывать и поддерживать свою доменную область.
Надоело не понимать, что происходит внутри вайбкод‑проектов