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

161–170 of 278 posts

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

#161

Post by NSPG911 »

Rapzid wrote: post #135
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 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?

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

#162

Post by noduerme »

wyre wrote: post #157
noduerme wrote: post #148

Question for people who have spent more time than I have wrangling agents to manage other agents: I've been using a Claude Pro plan just as a code analyzer / autocomplete for a year or so. But I recently decided to try to rewrite a very large older code base I own, and set up an AI management system for it. I started this last week, after reading about paperclip.ing. But my strategy was to layer the system in a way I…

Ya, openclaw is overkill for rewriting a codebase, especially when you're paying API costs. I developed my own task tracker (github.com/kfcafe/beans), i'm not sure how portable it is; it's been a while since i've used it in claude code. I've been using pi-coding-agent the past few months, highly recommend, it's what's openclaw is built on top of. Anthropic hasn't shut down Oauth, they just say that it's banned outsid…

I'm kinda doing this in a back-and-forth way over each section with openclaw, and one nice thing is that I've got it including the chat log for changes with each commit. I'm happy about how it's handled my personality as needing to understand all the changes it's making before committing. So I kind of want something interactive like that -- this isn't a codebase I can trust an LLM to just fire and forget (as evidenced by some massive misunderstandings about rewiring message strings and parameter names like "_meta" and ".meta" and "_META" that meant completely different things which the LLM accidentally crossed and merged at some point, before I caught it and forced it to untangle the whole mess -- which it only did well because there were good logs).

I sort of do need something with persistent memory and personality... or a way to persist it without spending a lot of time trying to bring it back up to speed... it's not exactly specific tasks being tracked, I need it to have a fairly good grasp on the entire ecosystem.

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

#163

Post by gbrindisi »

alasano wrote: post #60
gbrindisi wrote: post #14

I like openspec, it lets you tune the workflow to your liking and doesn’t get in the way. I started with all the standard spec flow and as I got more confident and opinionated I simplified it to my liking. I think the point of any spec driven framework is that you want to eventually own the workflow yourself, so that you can constraint code generation on your own terms.

I also like openspec. I think these type of systems (gsd/superpowers) are way too opinionated. It's not that they can't or don't work. I just think that the best way to truly stay on top of the crazy pace of changes is to not attach yourself to super opinionated workflows like these. I'm building an orchestrator library on top of openspec for that reason.

I am doing something similar: I use openspec to create context and a sequential task list that I feed to ralph loops, so that i’m involved for the planning and the verification step but completely hands off the wheel during code generation.

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

#164

Post by nelox »

mattmanser wrote: post #158
locknitpicker wrote: post #153

Earlier 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.

On the face of it is insulting, until you dig a little deeper

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

#165

Post by bubblerme »

The spec-driven approach resonates. I've found that the quality of the initial context you feed to AI coding tools determines everything downstream. Vague specs produce vague code that needs constant correction.

One pattern that's worked well for me: instead of writing specs manually, I extract structured architecture docs from existing systems (database schemas, API endpoints, workflow logic) and use those as the spec. The AI gets concrete field names, actual data relationships, and real business logic — not abstractions. The output quality jumps significantly compared to hand-written descriptions.

The tricky part is getting that structured context in the first place. For greenfield projects it's straightforward. For migrations or rewrites of existing systems, it's the bottleneck that determines whether AI-assisted development actually saves time or just shifts the effort from coding to prompt engineering.

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

#166

Post by polytely »

locknitpicker wrote: post #153
joegaebel wrote: post #146

In my view, Spec-Driven systems are doomed to fail. There's nothing that couples the english language specs you've written with the actual code and behaviour of the system - unless your agent is being insanely diligent and constantly checking if the entire system aligns with your specs. This has been solved already - automated testing. They encode behaviour of the system into executables which actually tell you if yo…

> 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

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

#167

Post by zby »

sveme wrote: post #159
zby wrote: post #152

Earlier quoted context omitted.

Spec Driven Development is a curious term - it suggests it is a kind of, or at least in the tradition of, Test Driven Development but it goes in the opposite direction!

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 system development.

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

#168

Post by wyre »

noduerme wrote: post #162
wyre wrote: post #157

Earlier quoted context omitted.

Ya, openclaw is overkill for rewriting a codebase, especially when you're paying API costs. I developed my own task tracker (github.com/kfcafe/beans), i'm not sure how portable it is; it's been a while since i've used it in claude code. I've been using pi-coding-agent the past few months, highly recommend, it's what's openclaw is built on top of. Anthropic hasn't shut down Oauth, they just say that it's banned outsid…

I'm kinda doing this in a back-and-forth way over each section with openclaw, and one nice thing is that I've got it including the chat log for changes with each commit. I'm happy about how it's handled my personality as needing to understand all the changes it's making before committing. So I kind of want something interactive like that -- this isn't a codebase I can trust an LLM to just fire and forget (as evidence…

how big is the codebase? how often is the agent writing to memory? you might be able to get away with just appending it to the project's CLAUDE.md? you might also want to check out https://github.com/probelabs/probe

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

#169

Post by anentropic »

I have been using this a lot lately and ... it's good.

Sometimes annoying - you can't really fire and forget (I tend to regret skipping discussion on any complex tasks). It asks a lot of questions. But I think that's partly why the results are pretty good.

The new /gsd:list-phase-assumptions command added recently has been a big help there to avoid needing a Q&A discussion on every phase - you can review and clear up any misapprehensions in one go and then tell it to plan -> execute without intervention.

It burns quite a lot of tokens reading and re-reading its own planning files at various times, but it manages context effectively.

Been using the Claude version mostly. Tried it in OpenCode too but is a bit buggy.

They are working on a standalone version built on pi.dev https://github.com/gsd-build/gsd-2 ...the rationale is good I guess, but it's unfortunate that you can't then use your Claude Max credits with it as has to use API.

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

#170

Post by noduerme »

wyre wrote: post #168
noduerme wrote: post #162

Earlier quoted context omitted.

I'm kinda doing this in a back-and-forth way over each section with openclaw, and one nice thing is that I've got it including the chat log for changes with each commit. I'm happy about how it's handled my personality as needing to understand all the changes it's making before committing. So I kind of want something interactive like that -- this isn't a codebase I can trust an LLM to just fire and forget (as evidence…

how big is the codebase? how often is the agent writing to memory? you might be able to get away with just appending it to the project's CLAUDE.md? you might also want to check out https://github.com/probelabs/probe

Hm. That looks a lot more granular, which is interesting... I'm not sure it would help me on this.

The codebase is small enough that I can basically go and find all the changes the LLM executed with each request, and read them with a very skeptical eye to verify that they look sane, and ask it why it did something or whether it made a mistake if anything smells wrong. That said, the code I'm rewriting is a genetic algorithm / evaluation engine I wrote years ago, which itself writes code that it then evaluates; so the challenge is having the LLM make changes to the control structure, with the aim of having an agent be able to run the system at high speed and read the result stream through a headless API, without breaking either the writing or evaluation of the code that the codebase itself is writing and running. Openclaw has a surprisingly good handle on this now, after a very very very long running session, but most of the problems I'm hitting still have to do with it not understanding that modifying certain parameters or names could cause downstream effects in the output (eval code) or input (load files) of the system as it's evolving.

Post reply on HN