When GSD Became the Bottleneck, I Built Something Lighter

I’ve tested a bunch of frameworks by now. I wrote extensively about GSD — Get Shit Done — and it’s still the heaviest, most complete way I know to build serious software with an LLM. Multiple phases, a roadmap, the whole thing.

But for the last month I was more in rocket-ship mode. Develop, release, develop, release, and so on. And GSD became the bottleneck. Not because it’s bad — it asks a lot of information up front, and then it tends to forget what it asked you. Which, if you’ve ever had to answer the same question twice in the same session, is genuinely frustrating. Sound familiar?

So I started putting together something lighter. Not a framework — I’d rather not call it that again. Let’s just say a way of working. A handful of steps I reach for now whenever I need speed more than ceremony.

Set the effort high, and don’t overthink the model

If something actually matters, I set the reasoning effort to X-High or even more — not the standard one. Always with Opus 4.8, and this kind of stuff. I don’t think Fable is needed right now, but that’s how it works at the moment.

That’s step zero. Everything else builds on top of it.

Ask for a plan, but only require two things

Here’s the part that replaces most of what GSD used to do for me: ask for a plan, and in that plan, require exactly two things.

First, document everything — update your docs folder, that kind of stuff. Second, create a UAT plan to be executed. If you don’t know what UAT is: user acceptance criteria, which means everything should be written from a user perspective, ready to be tested.

That’s it. Two requirements. Not twenty.

Round-based questions instead of granular ceremony

The only thing I ask for during the plan is, typically, I start with: “please do ten rounds of questions.” Then, during those rounds, depending on whether I realize the LLM is asking for something more, or there’s something else to cover, I keep going — “please do another five rounds,” something like that.

Rather than the super complex, super granular stuff, I use this basic technique to do the planning. If there’s something pretty easy, I’ll say three rounds, or five. If it’s something complex — ten, twenty, no more than that.

Big-bang across repos, then a handover

I hope you work with a single repo. I do prefer that. But in my case I have multiple repos, and rather than being interactive about it, I ask for big-bang style — do all the development in a single shot. Then, once everything is done, I do a handover with the other repository, or whatever else needs to happen next.

Two skills close the loop: UAT-define and UAT-execute

At the end, I have two skills. One is UAT-define, the other is UAT-execute. I ask it to please execute the UAT it just wrote.

This is useful because it runs the UAT in a basically automatic way — I use the Chrome DevTools MCP to actually drive the browser. And it returns a pre-tested version, maybe even with some fixes already applied.

That’s it.

No big framework. It works. The LLM will figure it out. That’s the reality.