It's almost once a week I see a very similar approach, with variables for the developer's workflow.
Sounds just like what I've been using, and published as a template: github.com/s1ugh34d/osc (It has a results corpus of testing done)
Specs that are LLM driven development, behavior addressed. All markdown human written, LLM's can write them too. The result is tight spec outcomes from LLM's assisting workflows.
Using massive human software specs was great with human developers, but with "clankers" the problem is context. How to wrap software contract context into a markdown file. Works for me, I can have Claude make a osc, review it, amend it, and build a simple solution that has verifiable outcomes.
This SpecDD is very similar, doesn't really need to book of documentation, just a guide really.
Not to be dismissive, this could lead to something interesting. But, it's funny how the spec.dd (https://specdd.ai/) example file is larger than what an actual implementation of the spec would be.
tl;dr: Small, scattered, files instead of one large one.
Usually when someone describes their new "language", or other text-based data format, they give examples of it in the announcement post. Maybe this isn't the announcement post? Regardless, it's the first one I see and my first impression is a big wall of words.
(Aside: Perhaps we should reserve the term "-driven-development" for more paradigm-shifty stuff? Just a thought.)
> Context is not just a technical limitation of current architectures. It is a fundamental property of how any intelligent system - biological or synthetic - reasons about complex problems.
Yes!
Now, please be respectful of my context window. Don't make one long document that demands I read the whole thing before I can even know if it's relevant to me.
I want entry points to hook me back into the body of the text when I start skimming for the useful bits. But the Contents headings on the left are just useless AI summaries.
Give me at least a hint of the bottom line up-front. Only buried deep in in the middle of the post, with no heading to call it out, I find "SpecDD is, at its core, a system for ...".
Sadly I have learned too little about "SpecDD" to form an opinion about it. But as a reader, I feel actively disrespected by the author.
How hard would it have been to create a test repo, make a branch with monolithic specs, make another branch with these scattered specs, run the same exact task against them both? Pick a few tasks. Run them a few times each. Analyze the results.
It's almost once a week I see a very similar approach, with variables for the developer's workflow.
Sounds just like what I've been using, and published as a template: github.com/s1ugh34d/osc (It has a results corpus of testing done) Specs that are LLM driven development, behavior addressed. All markdown human written, LLM's can write them too. The result is tight spec outcomes from LLM's assisting workflows.
Using massive human software specs was great with human developers, but with "clankers" the problem is context. How to wrap software contract context into a markdown file. Works for me, I can have Claude make a osc, review it, amend it, and build a simple solution that has verifiable outcomes.
This SpecDD is very similar, doesn't really need to book of documentation, just a guide really.
Not to be dismissive, this could lead to something interesting. But, it's funny how the spec.dd (https://specdd.ai/) example file is larger than what an actual implementation of the spec would be.
tl;dr: Small, scattered, files instead of one large one.
Usually when someone describes their new "language", or other text-based data format, they give examples of it in the announcement post. Maybe this isn't the announcement post? Regardless, it's the first one I see and my first impression is a big wall of words.
(Aside: Perhaps we should reserve the term "-driven-development" for more paradigm-shifty stuff? Just a thought.)
> Context is not just a technical limitation of current architectures. It is a fundamental property of how any intelligent system - biological or synthetic - reasons about complex problems.
Yes!
Now, please be respectful of my context window. Don't make one long document that demands I read the whole thing before I can even know if it's relevant to me.
I want entry points to hook me back into the body of the text when I start skimming for the useful bits. But the Contents headings on the left are just useless AI summaries.
Give me at least a hint of the bottom line up-front. Only buried deep in in the middle of the post, with no heading to call it out, I find "SpecDD is, at its core, a system for ...".
Sadly I have learned too little about "SpecDD" to form an opinion about it. But as a reader, I feel actively disrespected by the author.
Kudos...
I have noticed the same issue with agents/llms, and you appear to have solved it the best way possible. Spectacular! Thank you for sharing it openly!
Such a long blog post with so little evidence.
How hard would it have been to create a test repo, make a branch with monolithic specs, make another branch with these scattered specs, run the same exact task against them both? Pick a few tasks. Run them a few times each. Analyze the results.
LLM slop.