Я использовал VibeKanban , но потом также пришел к более простому подходу. В OpenSpec для каждого проекта просто добавил папку "board" , а в ней подпапки по этапам. Отредактировал skills, чтобы агент умел пользоваться "доской". Главное, к чему я пришел - не делать несколько worktree в одном репо. То есть отказался одновременно запускать разработку отдельными агентами несколько фич в одном репозитории. Основная причина - дорогой merge, а техдолг улетает в космос. Да и смысла особого нет - агент и так пишет очень быстро, а когда они в 3-5 потоков "выплевывают" фичу за фичей, то я не успеваю ни "принимать", ни описывать нормально новые фичи. А еще кайфа нет в таком потоке )))
Во-первых, агент — это не то же самое, что LLM. Токены «сжигаются» не самим фактом работы агента, а обращениями к модели. При нормальной архитектуре далеко не каждая операция агента требует вызова LLM: часть работы выполняется обычным кодом, правилами, пайплайнами, тестами, индексами, кэшем, статическим анализом и т.д.
Во-вторых, контроль и ревью тоже не обязательно должны полностью ложиться на человека. Первичный контроль должны выполнять другие агенты и автоматизированные проверки. Если говорим о коде, то код должен проверяться на соответствие спецификациям, контрактам, тестам, архитектурным ограничениям. Примерно как в API-first подходе: сначала человек утверждает контракт и требования, а потом реализация проверяется на соответствие этому контракту. В реальности, конечно, сложнее, но логика именно такая.
В-третьих, экономику можно достаточно грубо оценивать через объём создаваемых артефактов: код, тесты, спецификации, документацию. Несложный SaaS-продукт уровня «одна понятная функция для клиента» — это обычно не миллиарды токенов собственного кода, а скорее десятки тысяч строк. В токенах это может быть пара миллионов токенов итогового кода и, условно, сотни миллионов токенов на процесс разработки с итерациями, ревью, исправлениями и переписыванием.
Даже если взять порядок 200 млн токенов на разработку такого кода, это не выглядит как запредельная экономика для коммерческой разработки. У меня, например, за год очень плотного использования (15x7x365) coding-агентов получилось около 8 млрд токенов в рамках подписки, и это стоило порядка 2,4 тыс. долларов. Даже если представить команду из 10 человек с похожим режимом использования, это уже сравнимо не с «космическими расходами», а с небольшим бюджетом относительно ФОТ команды разработки.
И наконец, локальные модели и более дешёвые специализированные модели ещё сильнее меняют эту экономику. Да, они не бесплатные: появляется стоимость инфраструктуры, поддержки, качества и скорости. Но тезис о том, что агентная разработка обязательно упирается в неподъёмную стоимость токенов, на мой взгляд, сильно преувеличен.
Среднемагистральный самолет стоит порядка 100 млн. долларов. Их производят и успешно продают. Без высокотехнологичного производства самолето-строения не было бы как отрасли. Идея в том, что только изменение операционной модели производства интеллектуальных продуктов позволит не просто перейти на новый уровень производства, но и открыть целые новые отрасли или направления.
Хотел подсветить немного другое. На конвейере на вход подается заготовка/материал, а на выход получаем деталь/продукт. Конвейер позволил перейти на другой уровень производства продуктов. Но это не значит, что на заводе не нужны технологи, рабочие, мастера и так далее. Все эти люди обслуживаю конвейер, следят на качеством материалов и продуктов. Работа человека сместилась с "сделай все сам" на "управляй производством". AI-native это про "управление производством", где AI - это элемент в цепочке вашего конвейера создания интеллектуального продукта.
Спасибо за статью, очень близкий подход. Мне кажется, главный вывод тут не «RAG плохой», а то, что для агента, который работает с операционным состоянием бизнеса, vector search не может быть primary state store.
Я сейчас работаю над похожей агентный системой, но для финансового специалиста: платежные позиции, платежный календарь, заявки на оплату, поступления, дебиторка, кредиты, депозиты, прогнозные разрывы, история согласований и пр… И там этот тезис становится еще жестче. Если агент ответил «можно платить» или «через 10 дней кассовый разрыв», это не может быть результатом похожего чанка из базы. Нужны типизированные evidence-классы, прозрачная трасса до источника, дата актуальности, статус согласования/готовности, финансовая политика и понятная деградация, если фактов не хватает.
Из вашей архитектуры особенно ценно для меня отметил три вещи:
Типизированная память с confidence/evidence/author.
Детерминированная сборка контекста перед LLM.
Reflection-loop, который превращает события дня в новую управленческую память.
Спасибо автору стать и вам! Вы спасли меня. Симку купил на озон, казахскую (пару сотен рублей), воткнул в другой телефон, установил telegram, сделал пару сообщений, пару каналок, пару лайков. Зашел на https://my.telegram.org/apps (через мобильный интернет в роуминге!) Все сработало в первого раза.
VibeKunban и OpenSpec - на github в opensourse. Мой добавленный оркестратор - не выкладывал, так как не считаю это готовым продуктом. Писал чисто под себя. Но если кому-то очень надо - пишите в личку, с удовольствие поделюсь.
Честно - я не измерял. Не было такой задачи и не представляю как это сделать качественно. Разве что одну и туже задачу давать команде людей и команде агентов, а потом сверять показатели скорости и качества. Но одно я могу сказать точно - результат (готовый коммерческий продукт) я получил за 1 месяц и стоило это мне примерно 10 тыс. руб. за токены и часов 100 моего личного времени. По опыту, подобную задачу с командой 3-4 человека я бы делал месяца 3 (а, скорее всего, все 5) и стоило бы это мне в районе 1-2 млн. руб.
Согласен на 100%. На агентов нужно отдавать рутину, а потом еще и проверять реализацию. Я стараюсь максимально автоматизировать процесс тестирования и код ревью. Собственно, SDD подход, который реализует OpenSpec, и призван выстроить "контрактную" систему разработки, сделать разработку агентов более детерминированной.
Хороший вопрос. На уровне идеи пересечение есть: и там, и у меня речь про управление не одним агентом в чате, а несколькими агентами как рабочей системой.
Но фокус разный. Paperclip - это скорее готовый control plane для "AI-компании": org chart, роли, цели, бюджеты, governance, heartbeats, разные типы агентов и общий dashboard. То есть такой верхний организационный слой над процессами разработки.
У меня с "VibeKanban + OpenSpec+ кастомный Оркестратор" реализован более прикладной workflow, то есть тот самый процесс разработки вокруг конкретного репозитория-проекта: Kanban-стадии Explore → Spec → Apply → Verify → Test → Ship → Docs, отдельные worktrees, OpenSpec как внешний контракт контекста, CI как quality gate, retry policy и отдельный docs pipeline. То есть не про “AI-компанию”, как таковую, а непосредственно процесс доведения кодинг задачи от идеи до merge и документации.
Можно еще так сказать: Paperclip ближе к платформе управления агентной организацией, а мой эксперимент - к методологии и кастомному workflow для разработки. В будущем такие подходы вполне могут сходиться: Paperclip мог бы быть верхним control plane, а описанный мной pipeline нижним уровнем исполнения кодинг-задач.
Я использовал VibeKanban , но потом также пришел к более простому подходу. В OpenSpec для каждого проекта просто добавил папку "board" , а в ней подпапки по этапам. Отредактировал skills, чтобы агент умел пользоваться "доской". Главное, к чему я пришел - не делать несколько worktree в одном репо. То есть отказался одновременно запускать разработку отдельными агентами несколько фич в одном репозитории. Основная причина - дорогой merge, а техдолг улетает в космос. Да и смысла особого нет - агент и так пишет очень быстро, а когда они в 3-5 потоков "выплевывают" фичу за фичей, то я не успеваю ни "принимать", ни описывать нормально новые фичи. А еще кайфа нет в таком потоке )))
Тут важно разделять несколько вещей.
Во-первых, агент — это не то же самое, что LLM. Токены «сжигаются» не самим фактом работы агента, а обращениями к модели. При нормальной архитектуре далеко не каждая операция агента требует вызова LLM: часть работы выполняется обычным кодом, правилами, пайплайнами, тестами, индексами, кэшем, статическим анализом и т.д.
Во-вторых, контроль и ревью тоже не обязательно должны полностью ложиться на человека. Первичный контроль должны выполнять другие агенты и автоматизированные проверки. Если говорим о коде, то код должен проверяться на соответствие спецификациям, контрактам, тестам, архитектурным ограничениям. Примерно как в API-first подходе: сначала человек утверждает контракт и требования, а потом реализация проверяется на соответствие этому контракту. В реальности, конечно, сложнее, но логика именно такая.
В-третьих, экономику можно достаточно грубо оценивать через объём создаваемых артефактов: код, тесты, спецификации, документацию. Несложный SaaS-продукт уровня «одна понятная функция для клиента» — это обычно не миллиарды токенов собственного кода, а скорее десятки тысяч строк. В токенах это может быть пара миллионов токенов итогового кода и, условно, сотни миллионов токенов на процесс разработки с итерациями, ревью, исправлениями и переписыванием.
Даже если взять порядок 200 млн токенов на разработку такого кода, это не выглядит как запредельная экономика для коммерческой разработки. У меня, например, за год очень плотного использования (15x7x365) coding-агентов получилось около 8 млрд токенов в рамках подписки, и это стоило порядка 2,4 тыс. долларов. Даже если представить команду из 10 человек с похожим режимом использования, это уже сравнимо не с «космическими расходами», а с небольшим бюджетом относительно ФОТ команды разработки.
И наконец, локальные модели и более дешёвые специализированные модели ещё сильнее меняют эту экономику. Да, они не бесплатные: появляется стоимость инфраструктуры, поддержки, качества и скорости. Но тезис о том, что агентная разработка обязательно упирается в неподъёмную стоимость токенов, на мой взгляд, сильно преувеличен.
Среднемагистральный самолет стоит порядка 100 млн. долларов. Их производят и успешно продают. Без высокотехнологичного производства самолето-строения не было бы как отрасли. Идея в том, что только изменение операционной модели производства интеллектуальных продуктов позволит не просто перейти на новый уровень производства, но и открыть целые новые отрасли или направления.
Хотел подсветить немного другое. На конвейере на вход подается заготовка/материал, а на выход получаем деталь/продукт. Конвейер позволил перейти на другой уровень производства продуктов. Но это не значит, что на заводе не нужны технологи, рабочие, мастера и так далее. Все эти люди обслуживаю конвейер, следят на качеством материалов и продуктов. Работа человека сместилась с "сделай все сам" на "управляй производством". AI-native это про "управление производством", где AI - это элемент в цепочке вашего конвейера создания интеллектуального продукта.
Спасибо за статью, очень близкий подход. Мне кажется, главный вывод тут не «RAG плохой», а то, что для агента, который работает с операционным состоянием бизнеса, vector search не может быть primary state store.
Я сейчас работаю над похожей агентный системой, но для финансового специалиста: платежные позиции, платежный календарь, заявки на оплату, поступления, дебиторка, кредиты, депозиты, прогнозные разрывы, история согласований и пр… И там этот тезис становится еще жестче. Если агент ответил «можно платить» или «через 10 дней кассовый разрыв», это не может быть результатом похожего чанка из базы. Нужны типизированные evidence-классы, прозрачная трасса до источника, дата актуальности, статус согласования/готовности, финансовая политика и понятная деградация, если фактов не хватает.
Из вашей архитектуры особенно ценно для меня отметил три вещи:
Типизированная память с confidence/evidence/author.
Детерминированная сборка контекста перед LLM.
Reflection-loop, который превращает события дня в новую управленческую память.
Спасибо автору стать и вам! Вы спасли меня.
Симку купил на озон, казахскую (пару сотен рублей), воткнул в другой телефон, установил telegram, сделал пару сообщений, пару каналок, пару лайков.
Зашел на https://my.telegram.org/apps (через мобильный интернет в роуминге!)
Все сработало в первого раза.
VibeKunban и OpenSpec - на github в opensourse. Мой добавленный оркестратор - не выкладывал, так как не считаю это готовым продуктом. Писал чисто под себя. Но если кому-то очень надо - пишите в личку, с удовольствие поделюсь.
Честно - я не измерял. Не было такой задачи и не представляю как это сделать качественно. Разве что одну и туже задачу давать команде людей и команде агентов, а потом сверять показатели скорости и качества. Но одно я могу сказать точно - результат (готовый коммерческий продукт) я получил за 1 месяц и стоило это мне примерно 10 тыс. руб. за токены и часов 100 моего личного времени. По опыту, подобную задачу с командой 3-4 человека я бы делал месяца 3 (а, скорее всего, все 5) и стоило бы это мне в районе 1-2 млн. руб.
Согласен на 100%. На агентов нужно отдавать рутину, а потом еще и проверять реализацию. Я стараюсь максимально автоматизировать процесс тестирования и код ревью. Собственно, SDD подход, который реализует OpenSpec, и призван выстроить "контрактную" систему разработки, сделать разработку агентов более детерминированной.
Хороший вопрос. На уровне идеи пересечение есть: и там, и у меня речь про управление не одним агентом в чате, а несколькими агентами как рабочей системой.
Но фокус разный. Paperclip - это скорее готовый control plane для "AI-компании": org chart, роли, цели, бюджеты, governance, heartbeats, разные типы агентов и общий dashboard. То есть такой верхний организационный слой над процессами разработки.
У меня с "VibeKanban + OpenSpec+ кастомный Оркестратор" реализован более прикладной workflow, то есть тот самый процесс разработки вокруг конкретного репозитория-проекта: Kanban-стадии
Explore → Spec → Apply → Verify → Test → Ship → Docs, отдельные worktrees, OpenSpec как внешний контракт контекста, CI как quality gate, retry policy и отдельный docs pipeline. То есть не про “AI-компанию”, как таковую, а непосредственно процесс доведения кодинг задачи от идеи до merge и документации.Можно еще так сказать: Paperclip ближе к платформе управления агентной организацией, а мой эксперимент - к методологии и кастомному workflow для разработки. В будущем такие подходы вполне могут сходиться: Paperclip мог бы быть верхним control plane, а описанный мной pipeline нижним уровнем исполнения кодинг-задач.