Сравнительное исследование методов управления AI-разработкой · инсайты, кейсы, инструменты
Какую проблему решаем и что такое Definition of Done?
Доменные сущности, value objects и их связи
Стратегия: как достигнем требований
Куда изменение встраивается: компоненты, зависимости
Абстрактная стратегия → конкретные тестируемые шаги, до сигнатур методов
Сквозные инженерные нормы: нейминг, наблюдаемость, защитное кодирование
Незыблемые границы: инварианты, лимиты производительности, безопасность
Спека пишется до задачи и используется в workflow, затем удаляется.
Спека сохраняется после задачи для эволюции и поддержки. Правится вместе с кодом.
Спека — основной файл. Человек правит только спеку, код генерируется.
requirements → prompt → code
Сначала обнови Canvas через /spdd-prompt-update, потом перегенерируй код. Точечный дифф, не регенерация всего.
code → prompt
Сначала отрефактори код, потом /spdd-sync обратно в Canvas. Поведение не меняется — меняется запись.
Когда реальность расходится со спекой — сначала чини промпт, потом код. Так дрейф не накапливается: Canvas остаётся актуальным описанием системы, а не историческим снимком.
Почему 6 шагов, а не «план → код»: когнитивная нагрузка. Один большой ревью → скимминг и апрув по умолчанию → дрейф интента.
1 openspdd init в проекте. 2 /spdd-story — требование → user stories. 3 Вручную: core logic, границы scope, DoD с числами. 4 /spdd-analysis — сканирует только релевантный код. 5 /spdd-reasons-canvas — 7 слотов. 6 /spdd-generate + /spdd-api-test + unit-тесты.
Дальше: логика изменилась → /spdd-prompt-update, рефакторинг → /spdd-sync. Правило: сначала промпт, потом код (для рефакторинга наоборот).
1 uv tool install specify-cli. 2 specify init my-project --integration copilot. 3 /speckit-constitution — один раз на проект. 4 Цикл на фичу: /speckit-specify → /speckit-plan → /speckit-tasks → /speckit-implement → /speckit-converge (повторять до «Converged»).
Отдельные входы: specify extension add bug или assess. Артефакты: specs/00X-name/ (6–8 md) и .specify/.
1 Панель Specs → + (или Spec в чате). 2 Выбрать Feature или Bug. Для Bug создаётся bugfix.md из блоков current / expected / unchanged behavior. 3 Ревью трёх файлов: requirements.md → design.md → tasks.md. 4 Запуск задач: по одной или все (Kiro построит dependency graph и пойдёт волнами). Steering (product/tech/structure.md) — общий контекст. Для мелочей — Quick Spec.
1 tessl document --code src/renderer.js — получить спеку из кода. 2 Править только .spec.md (теги @generate, @test). 3 tessl build — генерация кода. Код помечается // GENERATED FROM SPEC - DO NOT EDIT, руками не трогать. Один spec ↔ один файл. Уровень spec-as-source.
1 npm i -g @fission-ai/openspec → openspec init. 2 Создать openspec/config.yaml с context и rules. 3 Цикл: /opsx:explore → /opsx:propose name → /opsx:apply → /opsx:archive. 4 План поменялся — /opsx:update name - что изменилось, apply продолжит с того же места. Дельта-спеки (## ADDED / ## REMOVED / ## RENAMED) накапливаются в openspec/specs/.
1 npx cc-sdd@latest (или --codex-skills --lang ru). 2 Точка входа: /kiro-discovery <идея> — сам маршрутизирует (расширить спеку / без спеки / одна / несколько). 3 Цикл: /kiro-spec-init → requirements → design → tasks → /kiro-impl. 4 /kiro-impl крутит автономно: свежий имплементер в TDD за feature flag + независимый ревьюер + auto-debug. Крупное — /kiro-spec-batch.
1 npx skills add bmad-code-org/BMAD-METHOD (выбрать bmad, bmod-core-tools, bmod-method). 2 Попросить агента выполнить bmad setup. 3 Вызвать bmad-build с задачей — метод сам выберет вход: смутная идея → Clarify, большая ясная → Plan, мелкое → Build and verify. 4 bmad status — что делать дальше. Модуль BMad Loop собирает и верифицирует целый эпик без человека.
1 Установка скриптом из buildermethods.com/agent-os. 2 /discover-standards — извлечь из кода ваши реальные конвенции (нейминг, логирование, исключения). 3 /inject-standards — подложить релевантные под задачу. 4 /shape-spec — усиленное формирование спеки. 5 /index-standards — поддерживать порядок. Применять до спека-инструментов.
1 Установить под харнесс: hermes plugins install obra/superpowers --enable / /plugin install superpowers@claude-plugins-official / /add-plugin superpowers. 2 Проверка: написать «Let's make a react todo list» — рабочий install автотриггерит brainstorming до кода. 3 Дальше по цепочке без команд: brainstorm → worktree → план (2–5 мин на задачу) → subagent на задачу + ревью → TDD RED-GREEN → финальный ревью ветки. 4 Диагностика: «figure out what went wrong with superpowers in this session».
Проблема не в генерации, а в управляемости. «Ferrari на грязной дороге»: локальная скорость ≠ throughput системы.
Промпт — артефакт первого класса. Версионируется рядом с кодом, ревьюится, переиспользуется.
REASONS = 7 слотов. Intent → design → execution → governance. Неизвестность сдвигается влево.
Двусторонний sync — ядро. Логика: prompt→code. Рефакторинг: code→prompt.
Три уровня зрелости. first → anchored → source. SPDD — anchored.
6 шагов — про когнитивную нагрузку. Один большой ревью не работает: скимят и апрувят по умолчанию.
Тесты не как в TDD. API-тесты раньше ревью, unit — последними. Интенция распределена.
Честные ограничения. Вариативность не устранена, hotfix откладывает governance, локальные модели не годятся.
Рынок размыт. «Spec» уже значит «детальный промпт». 9 инструментов — от лёгких до «Verschlimmbesserung».
Критерий Böckeler. Инструмент должен: держать разные размеры задач, давать хороший опыт ревью спеки, позволять итерации.
Держите spec.md / REASONS-lite в репо, коммитьте вместе с изменением.
Логика → спека сначала. Рефакторинг → спека после. Дрейф не накапливается.
Маленький баг ≠ Canvas на 16 AC. Лёгкий путь для мелочей, тяжёлый — для логически сложного.
Маленькие шаги вместо одного большого ревью плана.
Дешевле проверить «что» (API-тест), чем глубоко ревьюить неработающее.
REASONS-lite из 4–5 пунктов. Тренировать: abstraction-first, alignment, iterative review.