Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

github.com

Post reply on HN
Print view View original

121–130 of 278 posts

Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

#121

Post by DIVx0 »

lifeisstillgood wrote: post #95
DIVx0 wrote: post #93

I’ve tried GSD several times. I actually like the verbosity and it’s a simple chore for Claude to refresh project docs from GSD planning docs. Like most spec driven development tools, GSD works well for greenfield or first few rounds of “compound engineering.” However, like all others, the project gets too big and GSD can’t manage to deliver working code reliably. Agents working GSD plans will start leaving orphans a…

Can you expand on that at all (or point to some reading on how Claude plan mode works etc?) I think I have to get my head around a lot more than I think

claude code (CC) plan mode: In a normal CC window hit "shift-tab" until you see "plan mode on" in the lower left hand corner of the TUI.

Now all you really have to do is chat with claude about what you're thinking about building.

In plan mode, claude can't edit anything and has some extra "you're an expert at planning!" prompts prepended to your initial message in plan mode.

And then either when you're ready or Claude thinks the "plan" is gelling, it'll suggest stopping and let it write up a detailed plan. CC will dispatch some "planning agents" with prompts that your 'main' CC has crafted for that agent to plan for within the context of your conversation and what parts of the codebase it should look to integrate/explore.

Once all that is done, it will display it to you and then offer to "clear context and implement" - where it will just get to work. Or it will offer to go back to chatting and resolve whatever was misunderstood, or if you had a new idea you wanted to mix in.

These plans are saved as markdown in your .claude/plans directory.

Plan mode is handy on the on-off. But if you enter another plan mode, thinking claude would learn from, or build off a previous plan spec, it won't unless you explicitly say something like "read previous plan and re-use the scaffolding directives for this new project"

Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

#122

Post by marcus_holmes »

gtirloni wrote: post #21

I 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 rather than the actual destination. I'm looking forward to seeing where this journey ends up.

Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

#123

Post by prakashrj »

tkiolp4 wrote: post #52
prakashrj wrote: post #2

With GSD, I was able to write 250K lines of code in less than a month, without prior knowledge of claude.

That sounds awful. I got a promotion once for deleting 250K lines of code in less than a month. Now that sounds better

I get it now. Hopefully the utility of it will eventually bring some value. Maybe Utility and corresponding LOC should help you assess my work. Since I didn't share what I have, I can see people getting alarmed at 250K lines of code.

Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

#124

Post by canadiantim »

AndyNemmity wrote: post #117
canadiantim wrote: post #102

Earlier quoted context omitted.

you don't have to maintain it. Especially in the age of ai, just giving people inspiration and something to vibe from is more than sufficient and appreciated

alright. i guess i'll create a new repo, remove out a bunch of very specific pieces, and put it up. there's a lot of patterns i think are helpful for me.

That would be awesome. I believe with AI it's all about tailoring everything to your specific workflow and style, especially anything to do with the dev environment.

Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

#126

Post by AndyNemmity »

canadiantim wrote: post #124
AndyNemmity wrote: post #117

Earlier quoted context omitted.

alright. i guess i'll create a new repo, remove out a bunch of very specific pieces, and put it up. there's a lot of patterns i think are helpful for me.

That would be awesome. I believe with AI it's all about tailoring everything to your specific workflow and style, especially anything to do with the dev environment.

right, i'm having to cut out a lot of my pieces at the moment to try to get it into a release state.

i have checks of which types of repos i'm in with branching dev flows for each one.

it's going to be hard to communicate all of this genericly, but i am trying.

Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

#128

Post by tensegrist »

AndyNemmity wrote: post #117
canadiantim wrote: post #102

Earlier quoted context omitted.

you don't have to maintain it. Especially in the age of ai, just giving people inspiration and something to vibe from is more than sufficient and appreciated

alright. i guess i'll create a new repo, remove out a bunch of very specific pieces, and put it up. there's a lot of patterns i think are helpful for me.

if it's on github you could even archive it from the get-go

Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

#129

Post by ManWith2Plans »

Andrei_dev wrote: post #22

250K lines in a month — okay, but what does review actually look like at that volume? I've been poking at security issues in AI-generated repos and it's the same thing: more generation means less review. Not just logic — checking what's in your .env, whether API routes have auth middleware, whether debug endpoints made it to prod. You can move that fast. But "review" means something different now. Humans make human m…

I agree with this to some degree. Agents often stub and take shortcuts during implementation. I've been working on this problem a little bit with open-artisan which I published yesterday (https://github.com/yehudacohen/open-artisan).

Rather than having agents decide to manage their own code lifecycle, define a state machine where code moves from agent to agent and isolated agents critique each others code until the code produced is excellent quality.

This is still a bit of an token hungry solution, but it seems to be working reasonably well so far and I'm actively refining it as I build.

Not going to give you formal verification, but might be worth looking into strategies like this.

Re: Get Shit Done: A meta-prompting, context engineering and spec-driven dev system

#130

Post by roncesvalles »

hatmanstack wrote: post #41
gtirloni wrote: post #21

I 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…

Why are we using cli wrappers if you're using Claude Code? I get if you need something like Codex but they released sub agents today so maybe not even that, but it's an unnecessary wrapper for Claude Code.

So that you can have a fresh context for every little thing. These harnesses basically marry LLMs with deterministic software logic. The harness programmatically generates the prompts and stores the output, step by step.

You never want the LLM to do anything that deterministic software does better, because it inflates the context and is not guaranteed to be done accurately. This includes things like tracking progress, figuring out dependency ordering, etc.

Post reply on HN