There are so many of these "meta" frameworks going around. I have yet to see one that proves in any meaningful way they improve anything. I have a hard time believing they accomplish anything other than burn tokens and poison the context window with too much information.
What works best IME is keeping things simple, clear and only providing the essential information for the task at hand, and iterating in manageable slices, rather than trying to one-shot complex tasks.
Just Plan, Code and Verify, simple as that.
Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
171–180 of 278 posts
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#172I tried this but it creates a lot of content inside the repository and I don't like that. I understand these tools need to organize their context somewhere to be efficient but I feel that it just pollutes my space.
If multiple people work with different AI tools on the same project, they will all add their own stuff in the project and it will become messy real quick.
I'll keep superpowers, claude-mem, context7 for the moment. This combination produces good results for me.
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#173[flagged]
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#174Earlier quoted context omitted.
> This has been solved already - automated testing. This is specious reasoning. Automated tests are already the output of these specs, and specs cover way more than what you cover with code. Framing tests as the feedback that drives design is also a baffling opinion. Without specialized prompts such as specs, you LLM agent of choice ends up either ignoring tests altogether or even changing them to fit their own basel…
> Automated tests are already the output of these specs, and specs cover way more than what you cover with code. ok but how are you sure that the AI is correctly turning the spec into tests. if it makes a mistake there and then builds the code in accordance with the mistaken test you only get the Illusion of a correct implementation
> ok but how are you sure that the AI is correctly turning the spec into tests.
You use the specs to generate the tests, and you review the changes.
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#175There are so many of these "meta" frameworks going around. I have yet to see one that proves in any meaningful way they improve anything. I have a hard time believing they accomplish anything other than burn tokens and poison the context window with too much information. What works best IME is keeping things simple, clear and only providing the essential information for the task at hand, and iterating in manageable s…
Once the plan stage is done is it fire-and-forget for you afterwards?
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#176Earlier quoted context omitted.
> This has been solved already - automated testing. This is specious reasoning. Automated tests are already the output of these specs, and specs cover way more than what you cover with code. Framing tests as the feedback that drives design is also a baffling opinion. Without specialized prompts such as specs, you LLM agent of choice ends up either ignoring tests altogether or even changing them to fit their own basel…
I've seen a few comments recently that start with: This is specious reasoning It's an insulting phrase and from now on I'm immediately down voting it when I see it.
> It's an insulting phrase (
...)
I'm sorry you feel like that. How would you phrase an observation where you find the rationale for an assertion to not be substantiated and supported beyond surface level?
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#177I'm still stuck on superpowers. Can't seem to get better plans out of native claude planning - superpowers ensures I have a reviewed design that actually matches my mental model. Typical claude planning doesn't confirm assumptions sufficiently for my weak brain dumps/poorly spec'd tickets.
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#178I was using this and superpowers but eventually, Plan mode became enough and I prefer to steer Claude Code myself. These frameworks are great for fire-and-forget tasks, especially when there is some research involved but they burn 10x more tokens, in my experience. I was always hitting the Max plan limits for no discernable benefit in the outcomes I was getting. But this will vary a lot depending on how people prefer…
I ended up grafting the brainstorm, design, and implementation planning skills from Superpowers onto a Ralph-based implementation layer that doesn't ask for my input once the implementation plan is complete. I have to run it in a Docker sandbox because of the dangerously set permissions but that is probably a good idea anyway. It's working, and I'm enjoying how productive it is, but it feels like a step on a journey…
If it is working, why is it just a step on a journey? What is missing?
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#179There are so many of these "meta" frameworks going around. I have yet to see one that proves in any meaningful way they improve anything. I have a hard time believing they accomplish anything other than burn tokens and poison the context window with too much information. What works best IME is keeping things simple, clear and only providing the essential information for the task at hand, and iterating in manageable s…
[flagged]
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#180I used this for a team hackathon and it took way too much time to build understanding of the codebase, wrote too many agent transcripts and spent way too much token during generation. It also failed multiple times when either generating agent transcript or extracting things from agent transcript - once citing "The agent transcripts are too complex to extract from" - quite confounding considering it's the transcript you created.
For what we were trying to build - few small sets of features - using gsd was an overkill. The idea was to get some learnings whether gsd could be useful - for our case it was a strong no. Learning for me: don't overcomplicate - write better specs, use claude plan mode, iterate.