Комментарии 6
Вместо того чтобы сразу бросаться в реализацию, мы создаем "Change" - папку с описанием изменений.
Если я правильно понимаю, то разработка идёт путём создания цепочки таких папок (или замещении одной и той же по мере продвижения).
Вот это - выжимка LLM по основным папкам и файлам вашего подхода:
AGENTS.md ← правила мышления агента
openspec/
project.md ← контекст проекта
changes/
<id>/
proposal.md ← зачем
tasks.md ← что
spec(s)/spec.md ← как должно работать
design.md ← (опционально) архитектура
.beads/ ← как и в каком порядке делать
.cursor/commands/
openspec-to-beads.md ← формальный переход WHAT → HOWТакой вопрос: а где хранится целевой образ проекта в которым мы с агентами работаем? Описание того, что мы должны получить?
Это похоже на движение "отсюда и вперёд", а не "нам надо попасть туда".
Вы не можете хранить весь целевой образ проекта в одном файле project.md - это размывает контекст для каждой рабочей итерации агента. Там можно хранить базовые, глобальные ограничители и инструкции, которые именно что нужны для каждой рабочей итерации агента.
Спецификация держит рамки продукта
Если это про openspec/changes/ , то эта спецификация держит рамки изменения продукта. Рамки самого продукта в этом случае держит лишь код, который агент должен изменять. Со всеми вытекающими.
В этой статье я расскажу, как превратить хаотичный диалог с Cursor в структурированный инженерный процесс. Мы объединим два инструмента:
OpenSpec - чтобы зафиксировать "что и зачем мы делаем" (Spec-Driven Development).
Beads - чтобы управлять тем, "как и в каком порядке" это выполнять (граф задач).
Cursor - как среду, которая связывает их воедино.
Если вы устали от того, что ИИ теряет нить повествования на середине рефакторинга, этот подход для вас.
"никогда не было и вот опять..."
у меня cursor не нить повествования теряет, а сами правила, а вы предлагаете их еще усложнить. Вы вообще как-то боретесь с этим?
А еще зачем вы спамите хабр однотипными статьями? За два дня 4 статьи по "spec-driven development" (как вы его назвали) со слегка отличающимся смыслом. Не говоря уже о том, что это все статьи, целиком сгенеренные в ИИ.
За ссылки спасибо
Ещё фидбэк:
так совпало что использую клод код, там режим планирования сильно сокращает трату времени на разборы полётов
у антропика есть в целом рекомендации по работе с ИИ если ты разраб или просто домохозяйка
после некоторого активного повседневного использования ИИ больше смотрю в сторону простых prd/sdd/changelog, а сами таски в классическом понимании можно держать жире или гитхабе, да и ИИ умеет с ними вроде как работать норм
кроме бидса, спек дева в интернетах можно ещё найти вагон и тележку «д`Артаньян» подходов типа мы самый писк моды в сфере ии-ассистент разработки, но это кроме когнитивных нагрузок они мало что дают
реально хорошо сделан онбординг у антропика и помогают статьи по бестпрактиси с их оф блога, они похоже что-то публикуют у себя из комюнити
там что интересно так это +/- базовые подходы, кот можно применять и с другими ии
за ссылки спасибо. выпал с фразы "Разработчик с новой технологией - как маньяк с бензопилой, который носится по этажам психбольницы и пытается везде её применить." - это точно. опровбовал openspec, но bd пока еще не прикручивал,с openspec еще разбираюсь

Upgrade: OpenSpec и Beads в Cursor