В реальной работе я пользуюсь довольно простым spec-driven подходом. Смысл у него прямой: вынести намерение, research, архитектуру и tickets из памяти чата в файлы, которые можно читать, проверять и передавать дальше. Со временем я собрал повторяющиеся части этого цикла в SDDRush.
1. Какую проблему это решает
Старый сбойный сценарий никуда не делся: план живёт в чате.
Первые пару часов это выглядит быстро и даже удобно. Потом задача растягивается на ещё одну сессию, ещё одного инженера или ещё одного агента, и форма работы начинает плыть.
Обычно первым ломается вот что:
- исходное намерение размывается
- архитектура начинает приниматься кусками
- tickets перестают совпадать с реальным планом
- handoff начинает держаться на памяти и доброй воле
Именно это я и хочу убрать.
2. Что такое SDD на практике
На практике цикл довольно компактный:
- написать project brief
- собрать короткий и полезный research
- явно зафиксировать архитектурные решения
- синхронизировать backlog в конкретные tickets
- реализовать по открытому ticket
- обновить статус и закрыть то, что реально сделано
Ничего особенно экзотического тут нет. В этом и смысл. Я не пытаюсь превратить разработку в новую религию. Мне нужен след в репозитории, который переживёт больше одного разговора.
3. Что на деле даёт SDDRush
SDDRush — это маленький toolkit, который я собрал вокруг этого подхода.
Он берёт на себя те части, которые мне надоело каждый раз собирать вручную:
sdd-initсоздаёт.sdd-workspace и базовую структуру файловsdd-promptsрендерит repo-aware prompts из текущего состояния проектаsdd-backlogсинхронизирует и поддерживает backlog ticketssdd-statusбыстро показывает, что ещё открыто, а что уже уехало дальше
Этого уже хватает для многих задач. Если важен сам репозиторий, работа идёт дольше одной сессии и не хочется, чтобы brief растворился в фольклоре, такой scaffold полезен.
Quick start
bash bin/sdd-init /path/to/project --stack "Python/FastAPI" --domain "legal"
python bin/sdd-prompts /path/to/project
python bin/sdd-backlog sync /path/to/project
python bin/sdd-status /path/to/project
Дальше заполняешь ключевые .sdd-файлы, реализуешь по backlog/open, а потом прогоняешь janitor/status, когда состояние репозитория уже догнало план.
4. Где в этой схеме уместен Kotef
Если хочется продвинуть этот же цикл дальше, Kotef — это агентный слой, который я построил вокруг тех же идей.
Но я бы подавал его именно как более амбициозное продолжение, а не как вещь, с которой обязательно нужно начинать.
Kotef умеет:
- поднимать SDD-состояние для репозитория
- работать не от голого prompt, а от tickets и файлового контекста
- вести цикл planner -> researcher -> coder -> verifier -> janitor
- держать runtime state, checkpoints и resume для длинных задач
Это уже интересно, когда нужен durable coding and research agent для реальных репозиториев. Но базовая мысль не меняется: прежде чем давать агенту свободу, работе нужна структура.
5. Когда этот подход окупается
Я тянусь к такому циклу, когда:
- в задаче больше одного нетривиального решения
- контекст репозитория реально важен
- работа растянется больше чем на одну сессию
- кому-то ещё потом придётся разбираться, что именно произошло
Если задача крошечная и overhead будет дороже пользы, я этим не пользуюсь.
Я доверяю такому workflow и в задачах формата benchmark, где одновременно важны grounding, latency и telemetry. Актуальный пример — Agentic RAG Legal Challenge, где оценивают уже не один удачный prompt, а всю систему целиком.
Там хорошо срабатывает не драматизм, а дисциплина:
- маленькие изменения с понятной lineage
- жёсткие gates на grounding, latency и provenance
- быстрый отказ от веток, которые выглядят умно, но портят след доказательств
Не помогает без разбора расширять контекст, менять слишком много переменных за один прогон или верить более гладкому ответу раньше, чем стабилизировался путь, который к нему привёл.
6. Чего делать не стоит
Ошибки обычно довольно однотипные:
- превращать каждый маленький багфикс в церемонию
- запускать агента, пока сама задача ещё расплывчатая
- путать ответ модели с долговременной памятью проекта
- писать specs, которые звучат умно, но не ограничивают реализацию
Подход должен уменьшать объём угадывания. Если он в основном производит аккуратную бумагу, значит что-то пошло не туда.
7. Итог
Этот цикл полезен тем, что делает намерение более проверяемым, handoff более чистым, а состояние backlog — менее декоративным. SDDRush появился потому, что я достаточно часто работаю таким образом и хотел перестать вручную собирать скучные части. Kotef появился потому, что иногда мне хочется автоматизировать больше того же самого цикла, не теряя структуру по дороге.