GSD Framework Tackles AI Coding's Real Problem

The AI coding framework space has a selection problem masquerading as a competition problem. Developers pick based on what's trending or what worked for someone else's completely different project, then blame the framework when their agent spins off into context rot or over-engineers a simple feature.

The AI LABS team just released a walkthrough of GSD (Get Shit Done), positioning it against two other frameworks they've covered: BMAD and Superpowers. What's interesting isn't that GSD exists—new frameworks launch constantly—but that they're explicitly framing this as a matching problem. Different projects need different scaffolding around the same underlying models.

The Three Frameworks, Actually Different

GSD is built for projects where you're not entirely sure what you're building yet. Not "I have no idea" uncertainty, but "this requires experimentation at each step" uncertainty. The framework gathers broad scope upfront but doesn't lock you into later phases with extensive pre-planning. It plans implementation step by step, leaving room to pivot when the previous step reveals new constraints.

The AI LABS demonstration used an on-screen interview assistant as an example—something like Cluey, where you'd need to figure out UX patterns and how to avoid detection by screen-sharing platforms through actual testing, not upfront specification.

BMAD takes the opposite approach: thorough documentation for each phase before implementing anything. "You need to be sure about what you're building at the very start," the video explains. The framework includes what its creator calls a "research department"—pre-loaded context about different roles like business analysts and design thinkers that examine the product from multiple angles before generating PRD and architecture documents.

The AI LABS team praised BMAD's rigidity when they first covered it: "The system is so well built in the prompts that it doesn't really let the agent deviate from the tasks." But extended usage revealed the tradeoff. When requirements actually change, "even the best of the models actually miss little details." The framework's strength becomes its weakness—all those interconnected specs don't adapt gracefully.

Superpowers uses test-driven development, generating tests before code. It's designed for high-stakes scenarios where edge cases carry real cost—not Stripe integration bugs, but agentic platforms where AI agents take irreversible actions on behalf of users. The framework assumes you know what you're building and prioritizes preventing failures over enabling exploration.

Context Rot and the Sub-Agent Solution

GSD's architectural choice worth noting: it uses sub-agents for isolated tasks, spawning separate processes to keep the main agent's context clean. Most AI /article/superpowers-tries-to-teach-your-ai-agent-discipline coding agents now support this pattern, but GSD apparently optimizes for it specifically.

With Claude's new Opus 4.6 offering a 1 million token context window, the demonstration used 138,000 tokens for a full iteration—not much relative to the limit. But the framework doesn't rely on massive context windows. It maintains deliberately short documentation files so agents don't drift by getting "buried in documentation."

The project.md file that GSD creates after its initial questioning phase contains description, out-of-scope items, context constraints, and key decisions—all kept concise. Same with the context.md files created for each phase. This is architectural opinion expressed through constraints: the framework assumes verbose documentation causes more problems than it solves.

Adversarial Planning as Default

The most distinctive feature in the walkthrough: GSD performs adversarial planning automatically. It uses separate planning and verification agents—one creates plans, the other checks them and sends warnings back. The planning agent doesn't just write a plan one way; it "cross-verifies the plan across multiple dimensions and validates whether the plan is actually implementable and aligned with the goals."

This happens underneath, without manual intervention. The developer doesn't orchestrate the back-and-forth; the framework does.

Once a plan passes verification, GSD breaks it into waves, parallelizing independent work across sub-agents. It implements, then verifies checkpoints using Playwright testing—creating test scripts, running them, deleting them to keep the folder clean. The first iteration builds placeholders showing how the app will look. Further iterations build actual functionality one aspect at a time.

The Selection Criteria Nobody Uses

The video frames framework choice around three questions: How certain are your requirements? How costly are edge cases? How much does your spec need to evolve during development?

GSD: uncertain requirements, moderate edge case cost, high evolution expected. Use it for experimental MVPs or custom solutions that haven't been built before.

BMAD: certain requirements, moderate edge case cost, low evolution expected. Use it for conventional systems like custom CRMs or community platforms where you know what you want and just need it built correctly.

Superpowers: certain requirements, high edge case cost, low evolution expected. Use it when failures carry real consequences and you're willing to invest in comprehensive testing upfront.

The AI LABS team suggests a hybrid approach for projects spanning multiple domains: build core functionality with GSD where experimentation matters, then onboard Superpowers for high-stakes features that need TDD rigor.

What the Framework Actually Provides

GSD ships with multiple specialized agents mapped to appropriate models based on task weight. The research synthesizer uses Sonnet instead of Opus. Everything is structured in XML rather than Markdown because "Cloud models are known to work better with XML formatted instructions since it lets them parse the structure more easily."

It doesn't use straightforward git commits—it runs a script that performs checks first, ensuring everything meets standards before actually committing. When it conducts research, it spawns multiple agents in parallel, then uses a synthesizer agent to condense findings and flag potential long-term issues.

During the demonstration, one limitation surfaced: when conducting research, GSD used web search with "2025" in the keywords instead of using Context7 or looking up documentation properly. The team noted it would be "more controlled" with proper MCP connections for better grounding.

The Framework Isn't the Bottleneck

The video's core argument: "AI agents framework selection is the real bottleneck, not the framework itself." Developers waste time fighting their chosen framework because they picked based on popularity rather than fit.

For simple apps, the demonstration concludes, Claude or any agent on its own is sufficient—GSD would be overkill. "For simpler apps, Claude or any other agent on its own is sufficient and doesn't need this thorough planning." But for large-scale applications with multiple features where you want "controlled execution with proper planning without wasting too much effort," GSD's structure provides value.

The frameworks aren't competing to be universally best. They're solving different problems, and the selection criteria matter more than the feature lists. That's actually unusual in this space—most framework comparisons focus on capabilities, not use case matching. Whether developers will do the matching work instead of just picking whatever's trending is the real question.

—Dev Kapoor