Статья
Как я использую лёгкий spec-driven workflow в реальной работе, что автоматизирует SDDRush и где в этой схеме уместен Kotef.
В реальной работе я пользуюсь довольно простым spec-driven подходом. Смысл у него прямой: вынести намерение, research, архитектуру и tickets из памяти чата в файлы, которые можно читать, проверять и передавать дальше. Со временем я собрал повторяющиеся части этого цикла в .
Сбой старый и никуда не делся. План живёт в чате.
Первые пару часов это выглядит быстро. Потом задача растягивается на ещё одну сессию, ещё одного инженера или ещё одного агента, и форма работы начинает плыть.
Что ломается первым. Исходное намерение размывается. Архитектура принимается кусками. Tickets перестают совпадать с реальным планом. Handoff держится на памяти и доброй воле.
Именно это я и хочу убрать.
Цикл компактный:
Ничего экзотического. В этом и смысл. Я не пытаюсь превратить разработку в новую религию. Мне нужен след в репозитории, который переживёт больше одного разговора.
SDDRush - маленький toolkit, который я собрал вокруг этого подхода. Берёт на себя те части, которые мне надоело собирать вручную.
sdd-init создаёт .sdd-workspace и базовую структуру файлов. sdd-prompts рендерит repo-aware prompts из текущего состояния проекта. sdd-backlog синхронизирует и поддерживает backlog tickets. sdd-status быстро показывает, что ещё открыто, а что уже уехало дальше.
Этого хватает для многих задач. Если важен сам репозиторий, работа идёт дольше одной сессии и не хочется, чтобы brief растворился в фольклоре, такой scaffold полезен.
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, когда состояние репозитория уже догнало план.
Если хочется продвинуть тот же цикл дальше, Kotef - агентный слой, который я построил вокруг тех же идей. Более амбициозное продолжение. Не вещь, с которой обязательно начинать.
Kotef умеет поднимать SDD-состояние для репозитория, работать не от голого prompt, а от tickets и файлового контекста, вести цикл planner → researcher → coder → verifier → janitor, держать runtime state, checkpoints и resume для длинных задач.
Интересно, когда нужен durable coding and research agent для реальных репозиториев. Базовая мысль не меняется. Прежде чем давать агенту свободу, работе нужна структура.
Я тянусь к такому циклу, когда в задаче больше одного нетривиального решения, контекст репозитория важен, работа растянется больше чем на сессию, кому-то ещё придётся разбираться что именно произошло.
Если задача крошечная и overhead дороже пользы, не пользуюсь.
Доверяю такому workflow и в benchmark-задачах, где одновременно важны grounding, latency и telemetry. Актуальный пример — Agentic RAG Legal Challenge, где оценивают не один удачный prompt, а всю систему.
Там срабатывает дисциплина. Маленькие изменения с понятной lineage. Явные gates на grounding и provenance. Ветки, которые выглядят умно, но портят след доказательств, отрезаются рано.
Не помогает. Без разбора расширять контекст. Менять слишком много переменных за один прогон. Верить более гладкому ответу раньше, чем стабилизировался путь к нему.
Подход должен уменьшать объём угадывания. Если он в основном производит аккуратную бумагу, что-то пошло не туда.
Цикл полезен тем, что делает намерение проверяемым, handoff чистым, состояние backlog менее декоративным. SDDRush появился потому что я часто работаю так и хотел перестать вручную собирать скучные части. Kotef появился потому что иногда хочется автоматизировать больше того же цикла, не теряя структуру.