Adopting the GSD Framework for AI-Assisted Development

The Problem: AI Without a Plan

When I first started using Claude Code to help build my portfolio, the workflow was... chaotic. I'd throw a vague request at the AI, get a wall of code back, paste it in, fix the broken parts, and repeat. It worked, but it didn't scale.

The bigger the feature, the more context was lost between interactions. The AI would forget previous decisions, contradict earlier choices, or go off on tangents that I hadn't asked for. Sound familiar?

Enter GSD: Get Shit Done

GSD is a structured framework designed specifically for AI-assisted development. Instead of freeform conversations, it introduces a workflow with clear phases:

1. Project initialization — Define what you're building and why
2. Roadmap creation — Break the project into numbered phases with success criteria
3. Phase discussion — Surface gray areas and make decisions before coding
4. Phase planning — Create detailed execution plans with verification steps
5. Phase execution — AI executes the plan with atomic commits
6. Verification — Automated checks that the goal was actually achieved

What Changed for Me

Before GSD

me: "add a blog to my site"
ai: *writes 500 lines across 12 files*
me: "wait, that's not what I meant"
ai: *rewrites everything*
me: "closer, but the styling is wrong"
ai: *rewrites everything again*

After GSD

gsd: "What kind of blog? Static MDX, CMS, or database?"
me: "Static MDX with Velite"
gsd: "Tags? Search? Bilingual content?"
me: "All of that"
gsd: *creates a roadmap with 4 phases*
gsd: *plans phase 1 with specific tasks and verification criteria*
gsd: *executes with atomic commits I can review*

The difference isn't just efficiency — it's predictability. I know what's going to happen before it happens.

The Key Concepts

Phases Over Features

GSD doesn't think in "features" — it thinks in phases. Each phase has:

• A clear goal statement
• Success criteria that can be verified
• A plan with numbered tasks
• Atomic commits for each task

Discussion Before Planning

The discuss step is where GSD really shines. Before writing a single line of code, it asks questions about the gray areas — the decisions that would change the outcome:

• "Should the blog support draft posts?"
• "How should code blocks look in light mode?"
• "Do you want tags, categories, or both?"

These decisions get locked in a CONTEXT.md file that the planner and executor respect.

Quick Tasks for Small Stuff

Not everything needs a full phase. GSD has a quick mode for small, ad-hoc tasks — a bug fix, a styling tweak, a copy change. Same guarantees (atomic commits, state tracking), shorter path.

What I'd Tell Someone Starting Out

1. Don't fight the structure. It feels heavy at first, but the overhead pays for itself on the second phase.
2. Be honest in discussions. If you don't care about a decision, say "you decide." If you do care, be specific.
3. Use quick mode liberally. Not everything is a phase. The framework knows this.
4. Read the plans before executing. The AI can plan something technically correct but architecturally wrong for your project.

The Result

My portfolio went from a messy collection of AI-generated code to a structured project with clear history, atomic commits, and features that actually match what I intended. The blog you're reading right now was built with GSD.

Is it perfect? No. But it's the closest I've found to making AI-assisted development feel like pair programming instead of a coin flip.