GSD vs BMAD: Two Ways to Run Claude Code on a Real Project

I've been running Claude Code on Odisei Play - a production React Native app - for a few months now. My default workflow is GSD (Get Shit Done). Last week I spent a few hours reading through the BMAD Method documentation to understand what I'd been missing, if anything.

Here's what I found.

The problem both methods solve

When you give Claude Code a long task in a fresh session, it starts well. By the third or fourth file, it forgets constraints you set earlier. Patterns you agreed on get dropped. The agent makes a decision that contradicts something it said 40 messages ago.

Context rot is real, and both GSD and BMAD are structural responses to it. They just approach it differently.

GSD: small plans, atomic commits

GSD stands for "Get Shit Done." The core idea: stop treating a chat thread as your build system.

The workflow:

1. Discuss - lock down the product decisions before generating any plan. What exactly are we building? What constraints can't move? This happens in plain conversation.
2. Plan - turn the decisions into a small, concrete task spec. One thing, clearly scoped.
3. Execute - Claude Code runs the task in a fresh context against that spec.
4. Commit - one atomic git commit per task, so you can bisect when something breaks.

The fresh context per task is the key. You're deliberately limiting how much history the agent carries, which limits drift. The spec file travels with the session instead.

There's also a validation gate - the idea being that you need a working test feedback loop before the agent writes code. On a React Native project, this means keeping the spec tight enough that I can verify the output fast. If something breaks, I know exactly which task introduced it.

I'd been doing a version of this before I had a name for it. What GSD gave me was structure and language for a practice I was already doing intuitively.

What it looks like in practice

On Odisei Play, a typical GSD cycle for a feature:

• Draft a short task file: two or three paragraphs, acceptance criteria, what not to touch
• Open a fresh Claude Code session with that file as context
• Claude runs the implementation, I review the diff, we commit
• Next feature, new session

Overhead: 10-15 minutes of spec writing per task. That would have been 10-15 minutes of back-and-forth in a long-running session anyway - except now I have a document I can reuse.

The limitation is obvious: it scales with me. I'm writing the specs, reviewing the output, making the architectural calls. For a solo project, that's fine. For something larger, the single human in the loop becomes the bottleneck.

BMAD: agents before code

BMAD stands for "Breakthrough Method for Agile AI-Driven Development." Heavier framework. The idea is to run specialized agents - Analyst, PM, Architect, Dev, QA - that hand off to each other through structured documents before any implementation starts.

The phases:

1. Analyst - takes your rough idea, does research, produces a brief
2. PM - turns the brief into a PRD with stories and acceptance criteria
3. Architect - designs the technical approach, produces architecture docs
4. Dev - implements story by story, scoped against those docs
5. QA - validates against the original requirements

Each agent operates with a specific system prompt that limits what it sees and what it's allowed to do. A Scrum Master agent manages the story files passed between agents. They communicate through structured files, not through a shared context window.

The setup cost is real. You're configuring multiple agents, writing a PRD before touching code, and relying on inter-agent handoffs working correctly. For a new project with unclear requirements, this pays off. The planning work that would otherwise happen informally - or not at all - gets done explicitly before the agent writes anything.

Direct comparison

	GSD	BMAD
Setup	Low - one spec file per task	High - multi-agent config, PRD, architecture docs
Planning	Informal discuss phase	Structured agents (Analyst → PM → Architect)
Context	Fresh session per task	Structured docs passed between agents
Validation	Manual review + test gate	QA agent against PRD requirements
Best fit	Solo dev, production maintenance	Team projects, greenfield builds
Overhead	10-15 min per task	Hours upfront, then lower per-story cost

The key difference isn't the complexity of the workflow - it's when you do the hard thinking.

GSD pushes decisions into short discuss sessions before each task. You think task-by-task. BMAD front-loads all of it: by the time the Dev agent touches code, the architectural decisions are already in a document.

Neither approach lets you skip the thinking. They just schedule it differently.

Which one to use

Use GSD if:

• You're working alone or in a very small team
• You're maintaining or extending an existing codebase
• You want to ship incrementally without heavy upfront planning
• The feature scope fits in a short spec file

Consider BMAD if:

• You're starting a new project and requirements are genuinely unclear
• Multiple people are working with AI agents on the same codebase
• You've hit problems with agents making contradictory architectural decisions
• You want the planning phase to be auditable and reproducible

What I'm doing:

I stay on GSD for Odisei Play. The codebase is established, I know the architecture, and the planning overhead of BMAD would slow me down without much payoff. A task file per feature, fresh sessions, clean commits.

But if I were starting a new product from scratch - no existing code, real ambiguity in requirements - I'd seriously consider running a BMAD-style planning phase first, even with a simplified agent setup. The Analyst and PM phases alone would force me to write down decisions I'd otherwise make informally and forget.

The actual point

Both methods are doing the same thing: making implicit decisions explicit. You're externalizing what would otherwise live only in your head - or in the agent's context window where it'll decay.

The tooling is Claude Code. The methods are different ways of structuring what you hand to it.

Pick the one that fits the project you're actually building right now.