Live data from Hacker News

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

github.com

31–40 of 278 posts

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

#31

At the risk of sounding stupid what does the author mean by: “I’m not a 50-person software company. I don’t want to play enterprise theatre.” ?

The author of that page seems to mostly be AI, not a human.

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

#32

At the risk of sounding stupid what does the author mean by: “I’m not a 50-person software company. I don’t want to play enterprise theatre.” ?

No idea but doesn’t it sound GREAT and filled with portentous meaning? Don’t be an enterprise clown! Be a gutsy hustle guy like me! Down with enterprise theatre, long live the vibe jam!

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

#33

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 tried both. Each has pros and cons. Two things I don't like about superpowers is it writes all the codes into the implementation plan, at the plan step, then the subagents basically just rewrite these codes back to the files. And I have to ask Claude to create a progress.md file to track the progress if I want to work in multiple sessions. GSD pretty much solved these problems for me, but the down side of GSD is it takes too many turns to get something done.

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

#34

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…

[flagged]

This is clearly ai generated. Please no.

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

#36

At the risk of sounding stupid what does the author mean by: “I’m not a 50-person software company. I don’t want to play enterprise theatre.” ?

Seems fairly obvious: Some agent harnesses play enterprise theater by creating jira-type tickets for you and moving them around silly swim lanes, instead of, of course, just simply getting sh!t done.

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

#37
post #29

I could not produce useful output from this. It was useful as a rubber duck because it asks good motivating questions during the plan phase, but the actual implementation was lacklustre and not worth the effort. In the end, I just have Claude Opus create plans, and then I have it write them to memory and update it as it goes along and the output is better.

No brother, the Claude plans aren't the right path, they're for hobbyists.

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

#38

Earlier quoted context omitted.

I was not a app developer before, but a systems engineer with devops experience. But I learnt a lot about apple development, app store connect and essential became a app developer in a month. I don't think I can learn so quickly with other humans help.

If you lost access to AI would you be able to continue development on your app?

Goal is to build something that will have value. Once it has value, I can hire a team or open source it, if AI ceases to exist in this world.

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

#39

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 don't get why people need a cli wrapper for this. Can't you just use Claude skills and create everything you need?

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

#40
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, context budget. It never looks at what commands will actually run. So if the planner generates something destructive, the plan-checker won't catch it because that's not what it checks for. The gsd-verifier runs after execution, checking whether the goal was achieved, not whether anything bad happened along the way. In /gsd:autonomous this chains across all remaining phases unattended.

The granular permissions fallback in the README only covers safe reads and git ops — but the executor needs way more than that to actually function. Feels like there should be a permission profile scoped to what GSD actually needs without going full skip.

Post reply on HN