744 Sam Vs Get Shit Done 2efffa4f

Stateless Agent Methodology vs Get Shit Done (GSD)

A comparative analysis of two approaches to working effectively with LLM agents.

Executive Summary

Both methodologies address the same core problem: LLM agents optimize for apparent completion over correct completion, leading to quality degradation during extended work sessions.

Problem Statement Alignment

Both methodologies identify the same fundamental issues:

Shared Problem Analysis

The Core Dysfunction

Stateless Agent Methodology:

"Claude is not a knowledge worker—Claude is a stateless computation engine. LLM agents cannot perform JIT identification of knowledge gaps through self-reflection."

GSD:

"Context engineering hides complexity — plans capped at 2-3 tasks, fresh context per plan."

Both recognize that agents cannot self-assess, so the solution must externalize assessment.

Architectural Comparison

Phase Structure

Key Structural Differences

Detailed Phase Mapping

Phase 1: Discovery → Discuss Phase

Stateless Agent Methodology:

• User discussion following data-gathering framework
• Output: Feature requirements guide, NFR guide, notes

GSD:

• /gsd:discuss-phase N captures implementation preferences
• Identifies gray areas (visual features, API format, error handling)
• Output: {phase}-CONTEXT.md

Comparison: GSD is more structured — focuses specifically on gray areas and preferences that would otherwise become generic defaults. Stateless methodology is broader but less prescriptive.

Phase 2: Assessment → Research + Planning

Stateless Agent Methodology:

• Review goals, identify prerequisites
• Block planning until prerequisites verified
• Output: Feature design guide with verified prerequisites

GSD:

• 4 parallel research agents: stack, feature, architecture, pitfalls
• Creates {phase}-RESEARCH.md
• Plan verification before execution
• Output: Multiple {phase}-{N}-PLAN.md files

Comparison: GSD separates research (investigation) from planning (task creation). Stateless methodology combines prerequisite verification into a single assessment phase. GSD's parallel research is more sophisticated; stateless methodology's blocking requirement is more explicit.

Phase 3: Integration → Codebase Mapping

Stateless Agent Methodology:

• Map plan against existing code
• Identify conflicts, find reusable systems
• Add file/URL references
• Output: Contextualized implementation plan

GSD:

• gsd-codebase-mapper agent analyzes existing code
• Architecture research identifies patterns
• Plan files include <files> section with paths
• Output: Plans grounded in actual codebase

Comparison: Both require grounding plans in reality. GSD integrates this into the research phase; stateless methodology treats it as a distinct step. The intent is identical.

Phase 4: Task Generation → Plan Creation

Stateless Agent Methodology:

• Decompose into discrete tasks
• Follow: interfaces → failing tests → (implement → lint → test)
• Output: Task files with explicit constraints

GSD:

• Planner agent creates 2-5 atomic plans per phase
• XML structure: <name>, <files>, <action>, <verify>, <done>
• Each plan: 2-3 tasks maximum
• Output: {phase}-{N}-PLAN.md files

Comparison: GSD enforces small plan size (2-3 tasks) to prevent context degradation. Stateless methodology describes the pattern but doesn't enforce size constraints. GSD's XML format is concrete; stateless methodology is format-agnostic.

Phase 5: Execution → Execute Phase

Stateless Agent Methodology:

• Agent receives task file as complete prompt
• Task contains all necessary information
• Self-verification steps throughout
• Output: Completed work + self-verification

GSD:

• Fresh, bounded context per executor
• Wave-based parallel execution (pre-computed dependencies)
• One atomic commit per task
• Output: {phase}-{N}-SUMMARY.md + commits

Comparison: GSD's wave execution enables parallelism; stateless methodology is sequential. Both emphasize complete context per execution unit. GSD adds atomic commits as a key output; stateless methodology doesn't address version control.

Phase 6: Forensics → Verify Work

Stateless Agent Methodology:

• Independent verification of task completion
• Validate against plan
• Report status objectively
• Output: Complete/incomplete determination

GSD:

• /gsd:verify-work N runs UAT
• Extract testable deliverables
• Auto-diagnose failures with debugger agents
• Output: {phase}-UAT.md + fix plans if needed

Comparison: GSD includes automated debugging and fix generation. Stateless methodology stops at status determination. GSD's gap closure loop (--gaps flag) handles incomplete work automatically.

Phase 7-8: Orchestration + Verification → Complete Milestone

Stateless Agent Methodology:

• Orchestrator creates follow-up tasks
• Dispatches workers to incomplete tasks
• Final verification against goal and acceptance criteria
• Output: Feature sign-off or additional tasks

GSD:

• Workflow orchestration coordinates agents throughout
• /gsd:complete-milestone archives and tags
• /gsd:new-milestone starts fresh cycle
• Output: Git tag, archived milestone, next milestone setup

Comparison: GSD treats orchestration as continuous (throughout execution), not a separate phase. Milestone concept provides natural boundaries for releases.

Key Differentiators

What GSD Has That Stateless Methodology Lacks

What Stateless Methodology Emphasizes That GSD Assumes

Failure Mode Coverage

Complementary Strengths

Stateless Methodology Contributes

1. Theoretical foundation — Explains why the approach works
2. Agent-agnostic principles — Applicable beyond Claude Code
3. Explicit failure mode analysis — Diagnostic framework for new problems
4. Self-assessment thesis — Core insight that drives design decisions

GSD Contributes

1. Production-ready implementation — Immediately usable
2. Parallel execution model — Performance optimization
3. Git integration — Version control as first-class concern
4. Debugging automation — Self-healing workflow
5. Configuration system — Adaptable to different needs

Synthesis: A Unified View

Both systems share the same architecture when viewed abstractly:

┌─────────────────────────────────────────────────────────────────┐
│                    STATELESS AGENT PATTERN                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐  │
│  │ DISCOVER │───▶│  PLAN    │───▶│ EXECUTE  │───▶│ VERIFY   │  │
│  │          │    │          │    │          │    │          │  │
│  │ Complete │    │ Complete │    │ Complete │    │ Complete │  │
│  │ context  │    │ context  │    │ context  │    │ context  │  │
│  └──────────┘    └──────────┘    └──────────┘    └──────────┘  │
│       │               │               │               │         │
│       ▼               ▼               ▼               ▼         │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐  │
│  │ Artifact │    │ Artifact │    │ Artifact │    │ Artifact │  │
│  │ (reqs)   │    │ (plans)  │    │ (code)   │    │ (report) │  │
│  └──────────┘    └──────────┘    └──────────┘    └──────────┘  │
│                                                                 │
│  Key insight: Each phase receives COMPLETE context.             │
│  No phase depends on agent "remembering" anything.              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

The pattern:

1. Each phase gets complete context (stateless)
2. Each phase produces persistent artifacts
3. Artifacts become input to next phase
4. Assessment is externalized (separate agents/phases)
5. Verification is independent from execution

Recommendations

If Using Stateless Agent Methodology

Consider adopting from GSD:

• Wave-based parallelism for execution
• Atomic commits per task
• Gap closure loop for incomplete work
• Explicit state file across sessions
• Size constraints on task units (2-3 tasks max)

If Using GSD

The stateless methodology provides:

• Theoretical justification for why GSD works
• Framework for extending to non-Claude agents
• Failure mode vocabulary for debugging new issues
• Principles for designing new workflows

For New System Design

Combine:

1. Stateless methodology's principles — Design rationale
2. GSD's structure — Milestone/phase/plan hierarchy
3. GSD's execution model — Wave parallelism
4. Stateless methodology's forensics — Independent verification
5. GSD's automation — Debugging and gap closure

Conclusion

The Stateless Agent Methodology and Get Shit Done are the same insight at different abstraction levels.

• Stateless Agent Methodology = Why this works (theory)
• Get Shit Done = How to do it (practice)

Neither is complete without the other:

• Theory without implementation is academic
• Implementation without theory is fragile

Together they form a comprehensive approach to reliable LLM agent workflows.

References

• get-shit-done-cc (npm) (accessed 2026-01-26)
• get-shit-done-cc versions (npm) (accessed 2026-01-26)
• glittercowboy/get-shit-done (GitHub) (accessed 2026-01-26)
• Commands list (GitHub): commands/gsd/ (accessed 2026-01-26)
• Agents list (GitHub): agents/ (accessed 2026-01-26)
• Repo evidence (accessed 2026-01-26): package.json (version 1.9.13), plus counts observed in commands/gsd/ (27) and agents/ (11) from a local checkout of the same repository.