DSP vs GSD (Get Shit Done)

March 22, 2026 · View on GitHub

The real question

Modern AI coding agents — Claude Sonnet 4, GPT-4.1, Gemini 2.5 Pro — are already better at planning, structuring work, verifying output, and writing tests than most mid-level engineers. They don't need a wrapper to tell them how to plan. They don't need lifecycle phases imposed from outside. They already know.

The one thing they cannot do is remember your project between sessions.

Every new chat, every new task, every context window reset — the agent starts from zero. It re-reads files, re-discovers dependencies, re-learns what depends on what. On large codebases this "orientation tax" burns tokens, burns time, and produces worse results because the agent is working from incomplete information.

DSP fixes the actual problem. GSD wraps a problem that modern models have largely solved on their own.

What each actually does

DSP gives agents persistent structural memory. A graph of entities, dependencies, public APIs, and the reasons behind every connection — stored in .dsp/, versioned with git, readable in seconds. The agent opens a new session and immediately knows the project.

GSD gives agents a workflow wrapper. Structured phases (plan → execute → verify → ship), fresh-context management, wave execution. It tells the agent how to work — planning docs, verification steps, atomic commits.

The difference: DSP solves a problem agents genuinely have (no memory). GSD solves a problem that was real 12 months ago but that modern models handle natively.

Feature comparison

FeatureDSPGSD
Core ideaPersistent structural memoryProcess/confidence wrapper
What it solvesAgent has no memory of project between sessionsAgent doesn't follow structured workflow
Is the problem still real?Yes — no model has built-in project memoryPartially — modern models plan, verify, and ship without external phases
Memory / PersistenceFull graph persists across sessions, tools, branchesNo persistent project memory
Brownfield supportFirst-class — DFS bootstrap maps existing codebasesmap-codebase command — one-time scan, not persistent
Impact analysisBuilt-in — get-parents, get-recipients, get-childrenNot available
OverheadLow — memory layer, no ceremonyMedium — lifecycle phases, planning docs, verification steps
Installcurl | bash or irm | iexnpx get-shit-done-cc@latest
Codebase mappingFull entity graph with why for every edgeOne-time scan
Session continuityAgent reads .dsp/ — instant structural contextFresh-context model — each wave starts clean
Dependency discoverysearch, find-by-source, get-children — secondsRequires re-scanning or agent exploration
Reason trackingEvery import has a why; every export tracks who uses it and whyNot tracked
Git hooks / CIPre-commit, pre-push, GitHub ActionsGit hooks for workflow enforcement
Tool supportClaude Code, Cursor, CodexClaude Code, OpenCode, Gemini CLI, Codex, Copilot

Why agents don't need lifecycle wrappers

GSD's value proposition is: your agent needs structured phases, otherwise it produces chaotic output.

This was a reasonable claim in early 2025. It is increasingly untrue in 2026:

  • Planning — ask any modern agent to plan before coding and it will. It doesn't need /gsd:plan-phase to know that planning is useful.
  • Verification — agents already run tests, check types, lint code, and review their own output. They don't need /gsd:verify-work as an external trigger.
  • Atomic commits — any agent instructed to commit atomically will do so. This is prompt-level, not framework-level.
  • Fresh contexts — useful concept, but the agent can manage context windows without a wrapper orchestrating "waves."

What agents cannot do without external help:

  • Remember what src/services/payment.service.ts imports and why
  • Know that 7 modules depend on the auth middleware before you change it
  • Recall that the frontend config fetcher was refactored last week and moved to a new path
  • Navigate a 200-file codebase without loading everything into context

That's what DSP does. No other tool in the category addresses this.

Example: "Add authentication to an existing Express.js project"

With DSP + agent

# Agent starts a session — reads DSP for instant context
dsp-cli search "express app"
# obj-a1b2c3d4  [purpose] Express application entry point and middleware setup

dsp-cli get-children obj-a1b2c3d4 --depth 2
# Full dependency tree: routes → controllers → services → database

dsp-cli get-recipients obj-a1b2c3d4
# Every module that depends on the app setup

# Agent has full structural context in seconds.
# Plans, implements, tests, ships — using its own intelligence.
# Registers new entities as it goes:
dsp-cli create-object "src/middleware/auth.ts" "JWT authentication middleware"
dsp-cli add-import obj-a1b2c3d4 obj-NEW_AUTH "applies JWT auth to protected routes"

# Next session: agent reads DSP, sees auth already integrated, continues from where it left off.

With GSD + agent

# /gsd:plan-phase
# Agent scans codebase from scratch (expensive — reads dozens of files)
# GSD generates planning docs (agent could have planned without this)

# /gsd:execute-phase
# Wave 1: Create auth middleware (fresh context — re-reads relevant files)
# Wave 2: Create auth service (another fresh context — re-reads again)
# Wave 3: Integrate with routes (another fresh context — re-reads yet again)

# /gsd:verify-work
# Agent verifies (it would have done this anyway if asked)

# Next session: agent has no memory. Starts from zero again.
# No persistent knowledge that auth exists, what depends on it, or why.

The difference: with DSP, the agent spends tokens on work. Without it, the agent spends tokens on re-orientation — every single session.

What about using both?

You can use DSP alongside GSD. DSP provides memory; GSD provides workflow ceremony. If your team finds value in GSD's structured phases, DSP makes every phase faster and more accurate because the agent starts with structural context instead of re-scanning.

But the honest take: if the agent already has DSP's structural memory, much of GSD's value disappears. The agent doesn't need a wrapper to plan well when it already knows the full dependency graph. It doesn't need fresh-context waves when it can read .dsp/ and instantly understand the project.

Summary

DSPGSD
SolvesLack of persistent project memoryLack of structured workflow
Is the problem real in 2026?Yes — no model has built-in project memoryDiminishing — modern models are disciplined by default
What you needDSP + any modern agentGSD + hope the agent can't plan on its own
OverheadLowMedium
PersistenceFull graph across sessionsNone

The bottom line: modern agents are smart enough to plan, verify, and ship. They are not smart enough to remember your project. DSP is the fix. Everything else is optional ceremony.

Try it