GSD (Get Shit Done): The Framework That Changed How I Build Serious Software With AI

I talked in another article about the three modes of vibe coding I switch between. Today I want to go deep on the heaviest of the three: GSD — Get Shit Done.

This is a framework I discovered through a friend (gsd-build/get-shit-done). It honestly changed how I do code with LLMs. So if you’re serious about building real projects with AI — not just one-shot prompts — read on.

TL;DR — What GSD Is and When You Need It

GSD is a plugin. A combination of skills, slash commands, and scripts that guides you through the creation of any software using any LLM — Claude Code, Cursor, Codex, whatever you like.

When do you need it?

Whenever you want to develop something serious. Something with multiple phases. Something with a roadmap. A concrete project with different functionalities — not just a one-screen prototype.

The way I use it: I create the skeleton and the structure with GSD, then I test using it, and then I do the day-to-day work with a combination of Claude auto-edit, Claude bypass, or GSD itself when needed. GSD is the spine. The other modes are the muscles.

Setup: One Spoiler Before You Install

Before anything else: install GSD user-based, not project-based.

I cannot stress this enough. If you install it per project, every project ends up dragging all the dependencies along with it. It becomes a mess. User-based install = one source of truth, available across every repo. Trust me on this one.

The Mental Model: GSD Is Basically Jira Inside Your Codebase

Once installed, when you start working on a project, GSD creates a folder called .planning/ inside the repo. A lot of files. It can look overwhelming at first.

But the structure is simple if you map it to something you already know:

GSD is similar to Jira. Where Jira has initiatives, epics, and stories, GSD has milestones, phases, and cases.

That’s it. That’s the whole hierarchy:

• Milestone = the big chunk of value (think: “v1”, “first launch”)
• Phase = an increment of value inside that milestone (think: an epic — sometimes phases depend on each other, sometimes not)
• Cases = the actual tasks inside each phase

Once you see it as “AI-driven Jira,” the whole thing clicks.

The Flow: How You Actually Use It

Step 0 — Bring Context (PM Mindset)

Before I even open GSD, I open a normal chat with Claude or Cursor and just talk through what I want to build. Use cases. Requirements. The “why.”

This is the product manager mindset showing up. I’m not asking AI to do anything yet. I’m using it to clarify what I want.

When I feel I have enough context, I switch to GSD.

Step 1 — Create a New Milestone

You kick off a new milestone. If the repo is already existing, GSD dispatches an agent to analyze it first — so the AI has full context of what’s already there. Then you start adding your context: “here are my specs,” or “I already wrote everything down, please check the specs and give me the phases.”

GSD iterates for a while. And then it returns you the phases.

Each phase is an increment of value. Sometimes they have dependencies between them. Sometimes they don’t.

Step 2 — For Each Phase: Discuss

The first thing GSD does for a phase is the discussion. It iterates with you, sometimes proposing things itself, because it wants to really understand what you’re looking for.

It keeps asking questions until it reaches what it calls “enough context.” At that point, you and the AI are aligned.

This step is annoying if you’re impatient. But it’s the difference between a phase that ships and a phase that wastes your tokens.

Step 3 — For Each Phase: UI (If Needed)

This is a recent addition. If the phase requires UI work, GSD introduces a UI phase — basically writing everything about the UI: components, layout, design decisions — so the implementation stays compliant with what you actually want it to look like.

Before this addition, UI used to drift. Now it doesn’t. Big win.

Step 4 — For Each Phase: Plan

Now the real planning kicks in. And it has two sub-steps:

1. Discovery — GSD spawns another sub-agent to do all the discovery. For example, if you’re developing an API, it goes find out what already exists, what conventions to follow, what’s reusable. It does the homework for you.
2. The actual plan — once discovery is done, it writes the real plan.

My recommendation here: use Opus for planning, then use Sonnet for execution. Same project, two models. Why? Because planning needs the best brain. Execution is more mechanical — Sonnet does it just fine, for fewer tokens. Saves you real money.

Step 5 — Parallelize Across Phases

Here’s where it gets interesting. You don’t have to do this serially.

What I do: I run the first part — milestone + phase definition — all together. Then once the phases are divided, I work the different phases in different agents, different chats, different terminals — call it whatever you want.

I keep going until all the phases are ready to be executed. Then I trigger execution.

Working in parallel is a productivity multiplier most people don’t realize they have.

Step 6 — Autonomous Execution (The Magic Part)

This is where it gets wild — especially with the latest release.

GSD now detects dependencies between phases automatically. So you don’t have to manually orchestrate the order. It figures out: phase A must happen before phase B, phase C can run in parallel.

And if your phases are well planned, you can run the whole thing autonomously:

“Hey GSD, do all this autonomously.”

It starts running in waves, working on phases and cases that aren’t blocking each other, and just keeps developing.

Now here’s the technical beauty: when running autonomously, GSD spawns multiple sub-agents. Sub-agents have their own context. So even if one sub-agent fills its context window, the main orchestration doesn’t pollute. The main thread stays coherent across the whole project.

Imagine the workflow:

• I work during the day. I satisfy all the requirements, I write all the specs, I do the planning.
• At the end of the day I say: “please run everything autonomously.”
• I close the laptop.
• Boom. Ta-da. Next morning, everything is there.

That’s not a future promise. That’s how it works today.

Then Comes Testing — And Here Things Get Interesting Too

OK so you planned properly, you discussed properly, you even executed properly. Now what? Now it’s time to test. And there are two ways.

Manual Verification with /verify-phase

I work on multiple projects at the same time. Sometimes — let’s be honest — I don’t even remember what I was working on. The verify-phase command saves me here: it gives me a refresher of what was supposed to be built, and walks me through verification.

It’s human-in-the-loop: you can verify and tweak as you prefer. For each verification question, you basically answer yes / no / tweak.

If you say no, depending on the complexity:

• It might fix the issue immediately
• Or it queues the fix for the end of the validation, then reiterates
• Or — and this is what I do often — I open another terminal to fix it in parallel, so I can keep saying “yes, yes, yes” in the verify flow without blocking myself.

Generate End-to-End UAT Tests

At the end of verification, GSD can do something amazing. You can say: “Hey, I also want to create the end-to-end tests for this phase.”

And it generates all the UAT, all the tests — so next time, you can fully test this phase without doing the manual verification dance again.

This means: the first time through, you human-verify. From then on, the tests verify for you. Compounding investment.

Why This Matters (For Non-Developers Especially)

I started vibe coding seriously six months ago. And I can say it loudly: you can build serious applications without an engineering team.

Sure — you need a bit of technicality. You need to be curious. You need to ask the right questions. But that’s another story. You can survive without being a developer, which is what part of my identity as Alex-or-Alessio is all about.

GSD is what made this real for me. Because:

• It forces you to think before you build (discuss-phase)
• It captures decisions so you don’t lose them (.planning/ folder)
• It handles dependencies automatically
• It lets you parallelize across phases
• It runs autonomously while you sleep
• It generates the tests that protect what you built

That’s not “magic.” That’s structure applied to AI coding. Which is exactly what most vibe coders are missing.

Recap: When to Reach for GSD

To put it bluntly:

• Tiny fix? → auto-edit, don’t bother with GSD
• Single from-scratch feature? → planning mode, still no GSD needed
• Something bold, big, multi-phase, you want to track all the changes? → this is GSD’s home turf

If you want structure, if you want autonomous execution, if you want generated tests, if you want to be able to come back to the project in two months and still understand what’s going on — GSD is the answer.

Closing Thought

I’m not saying GSD is the only way. I’m not saying it’s free — it costs you time, tokens, and a learning curve. But I am saying this:

The difference between people who play with AI coding and people who build real things with AI coding is exactly this: structure.

GSD gives you that structure without making you become a developer. And in 2026, that’s about as good a deal as it gets.

So if you’ve got a real project lurking in your head — go install it (user-based, please!). Start a milestone. Let it ask you the annoying questions. And then watch it ship things while you sleep.

Thanks for reading. As always, I’m still experimenting. If something here doesn’t resonate, push back — I’d love to hear what mode works for you.