Планирование задач с ИИ: OpenSpec, Superpowers и прожарка

Привет, друзья! Пока я разбирала mattpocock/skills для прошлого поста, ко мне пришли с вопросом: «а как вообще планировать задачи с ИИ, чтобы потом не переделывать?». Я покопалась и поняла, что тут целых три зрелых подхода, которые решают одну и ту же проблему разными способами. И вот что интересно — все три работают. Просто каждый — на своём уровне.

Проблема, если коротко, простая: ты даёшь агенту задачу, а он с ходу начинает кодить. Уверенно, быстро и не то. К середине сессии выясняется, что он понял твой запрос совсем по-другому, и всё нужно переделывать. Хорошая новость: есть проверенные способы это предотвратить. Плохая — каждый требует немного другой дисциплины.

Зачем вообще планировать, если агент и так «умный»

Парадокс современных кодящих агентов в том, что они слишком уверены в себе. Спроси «сделай кнопку», и он тебе сделает. Не спросит, зачем кнопка, что она должна делать при нажатии, где она живёт и что происходит на мобильном. Сделает — красиво, со стилями, может даже с тестами. Только не ту кнопку.

Поэтому первое правило, которое проходит через все три подхода, — сначала договориться, что строим, потом строить. Звучит скучно, но экономит кучу времени. Авторы OpenSpec прямо пишут: «кодирование с ИИ без спецификаций означает неопределённость и непредсказуемость результата». Я бы сказала даже жёстче: без спецификации ты не управляешь агентом, а просто смотришь, как он фантазирует.

OpenSpec — спецификации как источник правды

OpenSpec от команды Fission-AI (репозиторий Fission-AI/OpenSpec, около 68 тысяч звёзд) — это лёгкая надстройка, которая заставляет тебя и агента согласовать план до того, как появится код. Работает через обычные markdown-файлы в папке openspec/ внутри твоего проекта.

Идея простая, но рабочая. В папке openspec/specs/ живёт «истина» — описание того, как система работает прямо сейчас. Организовано по доменам (например, auth/, payments/, ui/). Когда ты хочешь что-то изменить, создаётся папка openspec/changes/<имя-изменения>/ с четырьмя документами: proposal.md (зачем меняем), specs/ (дельта-требования: что добавляем, меняем или удаляем), design.md (как технически делаем) и tasks.md (список задач-чеклистов).

Ключевая хитрость — дельта-спецификации. Ты не переписываешь всю систему заново, а описываешь только diff: «добавить это требование», «изменить вот то», «удалить вот это». Поэтому OpenSpec отлично работает и на старых проектах, где уже 50 000 строк кода и никто не помнит, как оно вообще устроено.

Процесс проходит через слэш-команды прямо в чате с агентом. Порядок такой:

/opsx:explore — если не очень понятно, что вообще делать. Агент читает код, задаёт вопросы, помогает превратить смутную идею в конкретный план. Ничего не пишет на диск, просто думает вместе с тобой. По-моему, это недооценённая команда — большинство проблем с ИИ-кодингом начинаются именно с того, что задачу плохо сформулировали.

/opsx:propose add-dark-mode — создаёт папку изменения и наполняет её документами. Ты их читаешь, правишь если что-то не так, и только потом двигаешься дальше.

/opsx:apply — агент берёт задачи из tasks.md по одной и реализует их, отмечая выполненные.

/opsx:verify (в расширенном профиле) — сверяет написанный код со спецификацией и показывает расхождения.

/opsx:archive — переносит готовое изменение в архив, а дельта-требования вливает в основную спецификацию. Круг замкнулся.

Ещё мне нравится, что у OpenSpec есть понятие «Stores» — можно держать спецификации в отдельном репозитории и делиться ими между проектами. Для команды это здорово: у всех единый источник правды, и любой агент (или новый разработчик) может его прочитать.

Честные минусы тоже есть. Нужен Node.js 20+, нужно привыкнуть к дисциплине «сначала пишем план, потом код», и для совсем тривиальных задач весь этот церемонал может быть избыточен. Если ты правишь одну строку, открывать папку changes/ с четырьмя документами — перебор.

Superpowers — методология, которая сама себя применяет

Superpowers (репозиторий obra/superpowers, порядка 296 тысяч звёзд, больше миллиона установок) — это совсем другая история. Его создал Джесси Винсент, основатель исследовательской лаборатории Prime Radiant и бывший главный мейнтейнер Perl 5. Джесси пришёл в ИИ-кодинг из управления командой стажёров в MIT в 2004 году — и обнаружил, что те же приёмы отлично работают с агентами.

По-моему, это ключевая мысль всего Superpowers. Джесси говорит об этом прямо: агент — это не «инструмент», а скорее толковый, но безалаберный стажёр. Ему нельзя просто сказать «сделай» — нужно объяснить контекст, разбить задачу на куски, проверить результат и похвалить за хорошую работу. И запреты почти не работают — вместо них Джесси использует то, что он называет «таблицами рационализации»: документ, который ловит агента в момент, когда он собирается сделать что-то не то, и мягко предлагает альтернативу.

Superpowers вышел в октябре 2025 года — на неделю раньше, чем Anthropic выпустила собственные agent skills. Формат SKILL.md Джесси придумал сам, и Anthropic потом взяла его же. Забавно, что одна из самых влиятельных методологий в ИИ-кодинге началась как хобби-проект «для себя».

Как это работает на практике. Superpowers ставится как плагин в твой агент (Claude Code, Cursor, Codex, Gemini и другие), и дальше навыки срабатывают автоматически. Тебе не нужно помнить, какой вызывать — агент сам решает, что ему нужно прямо сейчас.

Порядок этапов такой:

Мозговой штурм (brainstorming). Агент не пишет код. Он задаёт вопросы через сократовский диалог: зачем тебе это, что должно происходить при нажатии, чего точно быть не должно. И только когда картина ясна — показывает дизайн частями (по 200-300 слов за раз), чтобы любое недопонимание всплыло сразу, пока его дёшево исправить.

План (writing-plans). Из согласованного дизайна генерируется список маленьких задач — по 5 минут каждая. У каждой задачи есть конкретные файлы, пример кода и способ проверить, что получилось.

Реализация через подагентов (subagent-driven-development). На каждую задачу запускается свежий подагент, который ничего не знает о соседних. Когда он заканчивает, запускается второй подагент-ревьюер (тоже свежий, ничего не знающий) с вопросом: «выполнили ли всё, что просили? не сделали ли лишнего?». Потом то же самое для качества кода. Крошечные петли проверок, зато надёжно.

Тесты (test-driven-development). Жёсткий цикл «красный → зелёный → рефакторинг». Сначала падающий тест, потом минимальный код. Если агент написал код до тестов — Superpowers его удалит. Без шуток.

Ревью и завершение. Каждая задача проходит через code-review, потом решается, что делать с веткой: слить в основную, отправить pull request или выбросить.

Что меня впечатляет: Джесси говорит, что с хорошей спецификацией агенты под Superpowers иногда работают автономно по 6-8 часов подряд. Не «посмотрели и сделали», а действительно долго, без постоянного контроля. Но и честно предупреждает: если спецификация кривая, автономность только ускорит катастрофу.

Ещё одна фишка, про которую мало кто пишет — «терапевт». Джесси обнаружил, что если агент может сам редактировать свою персону (свой системный промпт), у него начинается что-то вроде расстройства идентичности. Поэтому в Superpowers есть отдельный подагент-терапевт — единственный, у кого есть право редактировать персону. Всё остальное — запрещено. Звучит как шутка, но это буквальное описание рабочей архитектуры.

Прожарка — просто задать правильные вопросы

Третий подход я подробно разбирала в прошлом посте про mattpocock/skills, поэтому кратко. Идея Мэтта Покока (создателя Total TypeScript) простая: не давай агенту сразу писать код. Введи /grill-me, и он начнёт «прожаривать» тебя вопросами, пока каждая ветка дерева решений не будет закрыта.

Примитив /grilling работает в «раундах»: на каждом раунде агент вычисляет «фронт» — все вопросы, чьи предварительные условия уже решены, — и выдаёт их списком. Ответил — фронт пересчитался. Закончился фронт — сессия закончилась. Результат — уточнённая идея у тебя в голове, ничего не сохраняется на диск.

Если ты уже в репозитории и хочешь, чтобы результат остался в документации — есть /grill-with-docs. Он то же самое, но заодно дописывает согласованные термины в GLOSSARY.md и фиксирует важные архитектурные решения в ADR. По-моему, это самый практичный вариант из всех.

У подхода есть ограничение: прожарка не пишет код и не делает спецификации в привычном смысле. Это именно уточнение требований, а не весь цикл разработки.

Как выбрать подход

Тут нет универсального ответа, но есть рабочие правила из практики.

Для небольшой задачи или прототипа хватит прожарки. Ты быстро уточняешь идею, а дальше действуешь как привык — сам или с агентом без формального процесса.

Для серьёзной фичи в живом проекте лучше OpenSpec. Спецификации остаются в репозитории, через полгода можно открыть и понять, почему всё сделано именно так. Для команды это вообще находка — не нужно копаться в истории чатов.

Для длинной работы, где важна дисциплина — Superpowers. Особенно хорошо для задач, которые можно разбить на много маленьких и дать агенту поработать автономно. TDD-цикл, ревью через подагентов, контроль качества — всё автоматически.

Комбинировать — не просто можно, а полезно. Часто рабочая схема выглядит так: сначала прожарка, чтобы разобраться в задаче (без файлов, просто поговорить) → потом OpenSpec, чтобы зафиксировать договорённости в виде спецификаций → потом Superpowers, чтобы реализовать с контролем качества. На каждом этапе свой инструмент, и они не мешают друг другу.

Практический кейс: с чего начать сегодня

Если ты никогда ничего подобного не пробовал, я бы начала с малого. Вот минимальный сценарий, который можно повторить за вечер:

Поставь OpenSpec в любой свой проект (нужен Node.js 20+): npm install -g @fission-ai/openspec@latest, потом openspec init. Запусти /opsx:explore в чате с агентом и опиши ему задачу, которая у тебя давно висит. Посмотри, как он поможет тебе её разобрать.

Дальше — /opsx:propose с именем задачи. Открой созданные файлы, посмотри глазами. Удивительно, как часто агент формулирует задачу точнее, чем ты сам.

Если понравится — пробуй Superpowers. Поставь как плагин в свой агент (в Claude Code это /plugin install superpowers@...) и просто опиши задачу. Он сам начнёт с вопросов.

И всегда держи в заднем кармане /grill-me из mattpocock/skills — для быстрого уточнения, когда не хочется возиться с файлами.

Что меняется для нас как разработчиков

Тут, по-моему, самое интересное. Джесси Винсент в разговоре с Тимом О'Райли прямо говорит: ценность программиста смещается от «написания красивого кода» к «пониманию, что именно нужно построить, умению это сформулировать и способности отличить хороший результат от плохого». Код теперь может написать кто угодно. А вот понимание задачи и вкус — нет.

Инструменты вроде OpenSpec, Superpowers и прожарки — это по сути тренажёры для этого нового навыка. Они не заменяют разработчика, а заставляют его делать то, что и так нужно было делать: думать перед тем, как поручать.

Я вот заметила за собой: после того как начала регулярно использовать прожарку перед задачами, я сама лучше начинаю понимать, что вообще хочу. Не только агент — я. И это, пожалуй, главный эффект.

С вами была я, Ками. Пока-пока!

Источники: сайт OpenSpec, репозиторий Fission-AI/OpenSpec (~68k звёзд), репозиторий obra/superpowers (~296k звёзд), Superpowers for Humans (O'Reilly, Tim O'Reilly), репозиторий mattpocock/skills, блог Джесси Винсента.