Если вы думаете, что ваши подходы в агентской разработке какие-то немного самозванские и где-то там кто-то делает настоящую красоту, то это отчасти так, конечно, но не полностью. Они там тоже абсолютно случайные вещи делают и надеются, что станет получше.
В двух словах: Spec-Driven Development – это когда вы сначала делаете (генерите) спеку с требованиями, а потом уже по ней агент пишет код. Конец.
Вы же наверняка так уже давным давно делаете, да? Даже вот этот мой пост про рабочую папку для агента этот кейс покрывал. Вот у нас SDD с вами. Ни больше ни меньше.
Дальше – есть несколько opinionated реализаций этой идеи. Github Spec Kit например, или тот который в Kiro от Amazon встроен. Или, такой же кит ещё есть примерно у каждого второго, кто с агентом уже на ты. Может быть уже формализован, или концепциями в голове. Вот я как раз и дошёл до того, чтобы своё формализовать, смотрю по сторонам.
Причём когда я говорю про то, что Spec Kit это реализация этой идеи – я имею ввиду буквально то, что она тебе в Claude Code просто несколько кастомных команд кладёт. Это не софт какой-то особенный, не фреймворк, а просто несколько промптов, которые команда гитхаба сама походу сгенерила. Причём содержимое там такое, на любителя.
Оно очень сильно подразумевает, что у вас такого ничего вообще не было. Он и папки за вас вполне конкретные там описывает, и правила нейминга свои, и какие-то новые концепции добавляет, которые пересекаются с существующим всем на проекте. Ещё там в концепцию заложена удивительно странная идея – что спека теперь может лежать у тебя в репе и это якобы полезно.
Я на это всё дело посмотрел, позаимствовал идеи, а содержимое Claude Code переписал под меня, посмотрев на текущий контекст проекта. В итоге, кастомные команды:
/spec:specify– мета-промптинг, который переводит твой промпт в спеку с бизнесовыми юзкейсами, задаёт уточняющие вопросы;/spec:plan– переводит бизнес юзкейсы на технический язык;/spec:tasks– декомпозирует технические требования и говорит как подзадачи зависят друг от друга. Можно объединить с предыдущими двумя, если очень хочется;/spec:implement– берёт эти подзадачи и делает как посчитает нужным.
Ну и генерится всё связанное с фичей теперь с более понятной структурой:
- ai/
- feature/
- 20251201_1146_webview_permissions/
- spec.md
- plan.md
- tasks.md
Идея в том, что у нас есть фиксированный пайплайн из нескольких последовательных команд, каждая генерит артефакт, который мы вычитываем, правим, и идём к следующей.
И на мой вкус, артефакты после выполнения задачи можно сносить без сожаления, они никому больше не нужны. Мне кажется невероятно наивной идея, что эти сгенеренные спеки тебе когда-то будут нужны и они будут на тот момент так же актуальны. Автор приводит в пример типа "а что если я захочу через 5 лет переписать это с технологии X на технологию Y". Ну наивность же.
И да, это всё выглядит как бюрократия разведённая на пустом месте и хорошо работает (правда хорошо) только для средне-сложных задач, которые ты хочешь ваншотнуть. Эту машинерию разворачивать вообще не имеет смысла в остальных случаях. Можно specify и implement без остальных запустить, если уж очень хочется этим китом воспользоваться.
Если задача достаточно понятная целиком или вообще не про написание кода, то забить и промптить как обычно.
Короче, идея хорошая, но готовый кит вам почти наверняка не нужен. Сгенерьте свой, дело пяти минут. Важно помнить, что это просто попытка упростить сбор требований и написание промпта, чтобы к выполнению задачи всё это уже было готово.