Show HN: Spec-Driven Development Workflow for Claude Code
Spec Driven Development approach allows to squeeze more from coding agents thanks to few strong concepts:
- decomposition across two dimensions. first you generate specs in multiple steps (requirements, code analysis, design), than you split task into multiple subtasks and implement them one by one
- you clear context between every step - after spec generation and after subtask implementation. this helps keep cost low and context clear and focused which boost performance
- specs written to disk help with information persistency
- delivering specs layer by layer help to catch early when agent got you wrong
Repo with claude plugin for spec driven development: https://github.com/sermakarevich/sddw
(
12 comments
| 3 points
| on HN
)
I thought initially this meant that the spec wasn't detailed enough but the problem is more agent adherence and laziness.
Also sddw works nicely with fleet of agent: https://news.ycombinator.com/item?id=48226033. I just insert the sequence of sddw steps into the queue and take a nap.
I look at this as if there is a boundary of complexity behind which agents become behaving funky - we just need to find it. Its obvious that with simple tasks and clear instructions, agents don't have issues with adherence. This starts happening at some point when complexity is too high. We need to find this boundary and try to push it with approaches available on our side
I fail to see any backing for claims 'boosting performance' and 'keeping costs low'
here are slides explaining it in more details: https://docs.google.com/presentation/d/1SjKXF7hkoqyiN9-3tBGY...
when plan + code mode works - no need to change it. when it does not, because feature is complicated - than we need something else. Thats when sdd is applicable. I use it for mid + size projects only.
Measuring is a bit of subjective thing here. But when plan mode + code does not work and sdd works (because of double decomposition) - you get what you need.
Tokens consumption is lower because you can wipe your context after every step or subtask implemented. The scope to deliver specs is bigger however. But confusion is way lower as your context is focused per single step or subtask.
- fleet config set model=sonnet coder=claude
- fleet bd create --title "/sddw:requirements <task-name> task description is in TASK.md --auto"
- fleet bd create --title "/sddw:code_analysis <task-name> --auto" --deps <prev task id>
- fleet bd create --title "/sddw:design <task-name> --auto" --deps <prev task id>
- fleet bd create --title "/sddw:implement <task-name> --task 1 --auto" --deps <prev task id>