This pile of Markdown files has the most cringe-inducing name I have seen in weeks.
Having md files under "Languages" would be nice here.
Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
231–240 of 278 posts
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#232This pile of Markdown files has the most cringe-inducing name I have seen in weeks.
Surely gstack was worse, right?
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#233Please stop using the term prompt engineering, context engineering, etc. to define formatting the text that we send an LLM. Its already quite debatable whether software developers should be called software engineers, but this is just ridiculous.
Why?
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#234There 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…
There was a post from Apenwarr[1] recently that gave it a name: "the AI Developer’s Descent Into Madness", ending with "I need an agent framework. I can have my agent write an agent framework!" [1]: https://apenwarr.ca/log/20260316
Sounds like a FactoryFactory to me which tells me Java developers have always been mad
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#235Earlier quoted context omitted.
I use GitHub Copilot and unfortunately there has been a weird regression in the bundled Plan mode. It suddenly, when they added the new plan memory, started getting both VERY verbose in the plan output and also vague in the details. It's adding a lot of step that are like "design" and "figure out" and railroads you into implementation without asking follow-up questions.
> VERY verbose in the plan output Is that an issue? GitHub charges per-request, not per-token, so a verbose output and short output will be the same cost What model are you using?
The problem might be that our brains charge per token, which makes reviewing hard. :)
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#236Earlier quoted context omitted.
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…
I find simple Ralph loops with an implementer and a reviewer that repeat until everything passes review and unit tests is 90% of the job. I would love to do something more sophisticated but it's ironic that when I played both agents in this loop over the past few decades, the loop got faster and faster as computers got faster and faster. Now I'm back to waiting on agentic loops just like I used to wait for compilatio…
Curious what you mean by "played both agents" and "faster and faster"? API calls are API Calls or are you running an open-source model locally?
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#237Earlier quoted context omitted.
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…
did you hand modify the superpowers skills or are you managing this some other way?
For me, I just created my own prompt pipeline, with a nod towards GANs all of the necessary permissions get surfaced so I don't need to babysit it, and all are relatively simple. No need for Yolo or Dangerously setting Permissions.
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#238Earlier quoted context omitted.
Don't understand this - you can go spec -> test -> implementation and establish the test loop. Bit like the v model of old, actually.
SDD is about flowing the design choices from the spec into the rest of the system. TDD was for making sure that the inevitable changes you make to the system later don't break your earlier assumptions - or at least warn that you need to change them. Personally I don't buy TDD - it might be useful sometimes - but it is kind of extreme - but in general agile methodologies were a reaction to the waterfall model of syste…
This is just one way to use TDD. I personally get the most value from TDD as a design approach. I iteratively decompose the project into stubbed, testable components as I start the project, and implement when I have to to get my tests to pass. At each stage I'm asking myself questions like "who needs to call who? with what data? What does it expect back as a return value?" etc.
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#239[dead]
Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system
#240if you want to charge for this, or even if you don't and you want people in old & boring companies to use it, imagine a developer or engineer having this conversation with management/bureaucrats:
"I want to use 'get shit done' as part of my project"
These days, it's not a big deal at all at most places. But there are places where it will raise an eye brow. I'm not saying change it's name, and you've probably considered this already, but I would like to suggest the meaning of GSD tongue-in-cheek perhaps? Whatever, a kick-ass project either way.