Обновить

Комментарии 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 в структурированный инженерный процесс. Мы объединим два инструмента:

  1. OpenSpec - чтобы зафиксировать "что и зачем мы делаем" (Spec-Driven Development).

  2. Beads - чтобы управлять тем, "как и в каком порядке" это выполнять (граф задач).

  3. Cursor - как среду, которая связывает их воедино.

Если вы устали от того, что ИИ теряет нить повествования на середине рефакторинга, этот подход для вас.

"никогда не было и вот опять..."

у меня cursor не нить повествования теряет, а сами правила, а вы предлагаете их еще усложнить. Вы вообще как-то боретесь с этим?

А еще зачем вы спамите хабр однотипными статьями? За два дня 4 статьи по "spec-driven development" (как вы его назвали) со слегка отличающимся смыслом. Не говоря уже о том, что это все статьи, целиком сгенеренные в ИИ.

Ну, это весьма внятный обзор. Не знаю, как другие. Спасибо автору. Но к вопросу присоединяюсь.

За ссылки спасибо

Ещё фидбэк:

так совпало что использую клод код, там режим планирования сильно сокращает трату времени на разборы полётов

у антропика есть в целом рекомендации по работе с ИИ если ты разраб или просто домохозяйка

после некоторого активного повседневного использования ИИ больше смотрю в сторону простых prd/sdd/changelog, а сами таски в классическом понимании можно держать жире или гитхабе, да и ИИ умеет с ними вроде как работать норм

кроме бидса, спек дева в интернетах можно ещё найти вагон и тележку «д`Артаньян» подходов типа мы самый писк моды в сфере ии-ассистент разработки, но это кроме когнитивных нагрузок они мало что дают

реально хорошо сделан онбординг у антропика и помогают статьи по бестпрактиси с их оф блога, они похоже что-то публикуют у себя из комюнити

там что интересно так это +/- базовые подходы, кот можно применять и с другими ии

за ссылки спасибо. выпал с фразы "Разработчик с новой технологией - как маньяк с бензопилой, который носится по этажам психбольницы и пытается везде её применить." - это точно. опровбовал openspec, но bd пока еще не прикручивал,с openspec еще разбираюсь

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации