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

151–160 of 278 posts

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

#151

Post by nfg »

whalesalad wrote: post #138
Rapzid wrote: post #135

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

I find that even with opus 4.6, copilot feels like it’s handicapped. I’m not sure if it’s related to memory or what but if I give two tasks to opus4.6 one in CC and one in Copilot, CC is substantially better. I’ve been really enjoying Codex CLI recently though. It seems to do just as well as Opus 4.6, but using the standard GPT 5.4

As a matter of interest are you using the copilot cli?

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

#152

Post by zby »

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…

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!

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

#153

Post by locknitpicker »

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 baseless assumptions.

I mean, who hasn't stumbled upon the infamous "the rest of your tests go here" output in automated tests?

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

#154

Post by locknitpicker »

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 was using this and superpowers but eventually, Plan mode became enough and I prefer to steer Claude Code myself.

Plan mode is great, but to me that's just prompting your LLM agent of choice to generate an ad-hoc, imprecise, and incomplete spec.

The downside of specs is that they can consume a lot of context window with things that are not needed for the task. When that is a concern, passing the spec to plan mode tends to mitigate the issue.

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

#155

Post by hrmtst93837 »

yolonir wrote: post #19
maccam912 wrote: post #10

I've had a good experience with https://github.com/obra/superpowers . At first glance this looks similar. Has anyone tried both who can offer a comparison?

I've used both From my experience, gsd is a highly overengineered piece of software that unfortunately does not get shit done, burns limits and takes ages while doing so. Quick mode does not really help because it kills the point of gsd, you can't build full software on ad-hocs. I've used plain markdown planning before, but it was limiting and not very stable, superpowers looks like a good middleground

[flagged]

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

#157

Post by wyre »

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 outside of Claude Code. I'd recommend installing pi, tell it what you were doing with openclaw and have it port all of the information over to the installation of pi.

you could also check out ralph wiggum loops, could be a good way to rewrite the codebase. just write a prompt describing what you want done, and write a bash loop calling claude's cli pointed at the prompt file. the agent should run on a loop until until you decide to stop it. also not the most efficient usage of tokens, but at least you will be using Claude Pro and not spending money on API calls.

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

#158

Post by mattmanser »

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…

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.

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

#159

Post by sveme »

zby wrote: post #152
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…

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.

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

#160

Post by patates »

annjose wrote: post #49
maccam912 wrote: post #10

I've had a good experience with https://github.com/obra/superpowers . At first glance this looks similar. Has anyone tried both who can offer a comparison?

I tried Superpowers for my current project - migrating my blog from Hugo to Astro (with AstroPaper theme). I wrote the main spec in two ways - 1) my usual method of starting with a small list of what I want in the new blog and working with the agent to expand on it, ask questions and so on (aka Collaborative Spec) and 2) asked Superpowers to write the spec and plan. I did both from the working directory of my blog's…

I usually ask Gemini to review the spec as well. Sometimes it catches things I missed even after going through a few times.
Post reply on HN