Comments 18
А чем Ваш подход отличается от “Paperclip”?
Хороший вопрос. На уровне идеи пересечение есть: и там, и у меня речь про управление не одним агентом в чате, а несколькими агентами как рабочей системой.
Но фокус разный. 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 нижним уровнем исполнения кодинг-задач.
Месяц назад писал про пакет скилов от CEO Y Combinator. Очень похожий процесс и парадигма.
С агентами вот такая штука, по моей практике (системный архитектор вот тут).
Составление спецификаций (ТЗ) занимает процентов 80% времени, и агент составить её самостоятельно не может, тут польза в “парном проектировании”. На этапе construction надо смотреть, что эти агенты делают, причём детально, иначе накапливается Comprehension Debt.
По моему опыту для прототипа или MVP все эти привлечения “команд агентов” хороши. Для продукта в активной эксплуатации использовании ИИ более напоминает использование экзоскелета, чем использование дополнительной команды агентов-инженеров.
Согласен на 100%. На агентов нужно отдавать рутину, а потом еще и проверять реализацию. Я стараюсь максимально автоматизировать процесс тестирования и код ревью. Собственно, SDD подход, который реализует OpenSpec, и призван выстроить "контрактную" систему разработки, сделать разработку агентов более детерминированной.
В своё время я уже присматривался к OpenSpec, но остались несколько неясностей, из-за которых мы тогда не стали его внедрять. Хотелось бы поделиться наблюдениями.
В README.md /opsx:propose и /opsx:apply подаются как ключевые команды, однако в спеках их описания нет. Зато присутствуют specs/ai-tool-paths/spec.md и artifact-graph/spec.md, которые, на мой взгляд, относятся скорее к внутренним контрактам, чем к user-facing.
В целом, складывается впечатление, что у OpenSpec пока есть сложности с тем, чтобы отразить собственный functional design.
Что касается technical design - я не нашёл, где можно посмотреть текущую архитектуру: какие есть компоненты, кто кого вызывает, как устроены границы. README.md предлагает выполнить npm install -g @fission-ai/openspec@latest, но мотивация именно такого шага на этом этапе для меня не вполне очевидна.
В текущем виде, для задач моей области, этого, к сожалению, оказывается недостаточно.
Добрый день. Скажите, пожалуйста: к каким количественным и качественным показателям привело внедрение вашего эксперимента в рабочие процессы? Например, в сравнении с живыми людьми?
Честно - я не измерял. Не было такой задачи и не представляю как это сделать качественно. Разве что одну и туже задачу давать команде людей и команде агентов, а потом сверять показатели скорости и качества. Но одно я могу сказать точно - результат (готовый коммерческий продукт) я получил за 1 месяц и стоило это мне примерно 10 тыс. руб. за токены и часов 100 моего личного времени. По опыту, подобную задачу с командой 3-4 человека я бы делал месяца 3 (а, скорее всего, все 5) и стоило бы это мне в районе 1-2 млн. руб.
Начинающие разработчики зарабатывают на зелёных строчках коммитов, опытные — на красных, а лучшие — на строчках, которые никогда не были написаны. И в этом весь парадокс пути программиста: чем ты опытнее, тем меньше следов ты оставляешь в репозитории.
Ещё одна сказка ? Пруфы будут ? Возможно ли попробовать "фрейморк" ?
Интересный опыт. Канбан-продуктивный подход
Статья тоже завайбкодена агентом? И щас за это перестали минусовать. Люди что с вами???)
А openspec разве не создает документацию? Зачем еще отдельный процесс? Или она «специфическая»?
Я «нанял» AI-команду разработки и управлял ею через Kanban: опыт на реальном продукте