Live data from Hacker News

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

github.com

41–50 of 278 posts

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

#41

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.

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

#42

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…

You can AI to audit and review. You can put constraints that credentials should never hit disk. In my case, AI uses sed to read my env files, so the credentials don't even show up in the chat.

Things have changed quite a bit. I hope you give GSD a try yourself.

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

#43

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…

[deleted]

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

#44

The README recommends --dangerously-skip-permissions as the intended workflow. Looking at gsd-executor.md you can see why — subagents run node gsd-tools.cjs, git checkout -b, eslint, test runners, all generated dynamically by the planner. Approving each one kills autonomous mode. There is a gsd-plan-checker that runs before execution, but it only verifies logical completeness — requirement coverage, dependency graphs…

[deleted]

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

#45

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…

Code is a cost. It seems everyone's forgotten. Saying "I generated 250k lines" is like saying "I used 2500 gallons of gas". Cool, nice expense, but where did you get? Because it it's three miles, you're just burning money. 250k lines is roughly SQLite or Redis in project size. Do you have SQLite-maintaining money? Did you get as far as Redis did in outcomes?

Openclaw was mostly build by AI. It had 400K lines of code.

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

#46
post #34

Earlier quoted context omitted.

[flagged]

This is clearly ai generated. Please no.

Sorry about that. I'm new here and English isn't my first language, so I leaned on tools to help me phrase things and it ended up looking like a bot. Lesson learned-I'll stick to my own words from now on. The point is real though. I've actually been building a multi-agent system and that separation between coder and reviewer is a game changer for catching bugs that look fine on the surface. Anyway, won't happen again.

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

#47

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?

Yes, and IMO Superpowers is better when you want to Get Not-Shit Done.

Get Shit Done is best when when you're an influencer and need to create a Potemkin SaaS overnight for tomorrow's TikTok posts.

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

#48
post #3

Earlier quoted context omitted.

I could copy 250k lines from github. Faster than using ai. Cheaper. Code is better tested/more secure. I can learn/build with other humans.

This is how I test my code currently. 1. Backend unit tests — fast in-memory tests that run the full suite in ~5 seconds on every save. 2. Full end-to-end tests — automated UI tests that spin up a real cloud server, run through the entire user journey (provision → connect → manage → teardown), and verify the app behaves correctly on all supported platforms (phone, tablet, desktop). 3. Screenshot regression tests — ev…

Check out exe.dev/Shelley web agent it facilitates much of what you describe by default.

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

#49

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 repo so that the agent has full access to the code and the content.

My findings:

1. The spec created by Superpowers was very detailed (described the specific fonts, color palette), included the exact content of config files, commit messages etc. But it missed a lot of things like analytics, RSS feed etc.

2. Superpowers wrote the spec and plan as two separate documents which was better than the collaborative method, which put both into one document.

3. Superpowers recommended an in-place migration of the blog whereas the collaborative spec suggested a parallel branch so that Hugo and Astro can co-exist until everything is stable.

And a few more difference written in [0].

In general, I liked the aspect of developing the spec through discussion rather than one-shotting it, it let me add things to the spec as I remember them. It felt like a more iterative discovery process vs. you need to get everything right the first time. That might just be a personal preference though.

At the end of this exercise, I asked Claude to review both specs in detail, it found a few things that both specs missed (SEO, rollback plan etc.) and made a final spec that consolidates everything.

[0] https://annjose.com/redesign/#two-specs-one-project

Post reply on HN