Using the Get Sh*t Done (GSD) Framework for AI Coding
Overview
I tested three spec-driven development (SDD) platforms: Amazon Kiro, Superpowers, and (the focus here) Get Sh*t Done (GSD). All three address the same core problem: agentic coding without structure drifts from architecture and eventually fails in production. Each of the three tools enforces structure differently.
- Amazon Kiro enforces structure at the tooling level. Kiro transforms prompts into formal requirements, matches designs to the codebase, and maps task lists to requirements. The IDE makes it structurally difficult to skip these steps.
- Superpowers enforces structure at the skill/behavioral level. The agent will refuse to write code before a design is approved and tests are created.
- GSD enforces structure at the context-orchestration level: fresh subagents, atomic commits, and state persisted to disk.
With Kiro, I built a data visualization application. With Superpowers, I extended it to include comparative analytics. With GSD, I took on the most ambitious scope yet: adding real-time streaming of millions of records into a complex UI providing at-a-glance communication state across nine frequency bands.
Why GSD Was My Favorite
Of the three platforms, GSD was my favorite. Not perfect, but I felt in control. I could apply structure where it made sense and bypass it where it didn’t. The interface was clean and next steps were always surfaced. That’s a significant contrast to Kiro and Superpowers, where I was often unsure what was happening or what came next.
The main friction: GSD’s reliability depends on keeping tasks well supplied with context across Claude’s 200K token window. That translates into a recurring loop of writing state to disk, clearing the context, and having the agent rediscover state from disk artifacts before proceeding. It got tedious, but context did not drift.
Setup and Process
GSD setup took under five minutes. The /gsd:map-codebase command populated GSD’s disk artifacts with the existing codebase structure and, in doing so, flagged several issues with the existing code.
The 40-page slash command reference was initially daunting. The agent’s clarification was helpful:
“There are three layers. Setup runs once (map-codebase, new-project, create-roadmap). The phase loop repeats per phase (discuss → execute → verify). Everything else is situational.”
The three core phase commands:
- /gsd:discuss-phase captures vision and intent; produces CONTEXT.md
- /gsd:plan-phase researches the codebase and produces PLAN.md with task breakdown, threat model, and success criteria
- /gsd:execute-phase works through the plan and produces SUMMARY.md on completion
After running /gsd:new-project and supplying an objectives document, the agent asked three clarifying questions, then suggested handling the minor objectives first and deferring the major feature to a separate milestone. It immediately started fixing bugs and implementing minor enhancements (low overhead, effective).
The agent clarified that it was operating with a light touch because a design document already existed. For the full structured process, you need to invoke the phase commands above explicitly to generate the artifacts that drive the workflow.
Design Phase
The design process was one of GSD’s strengths. The agent presented a list of topics; for each topic I chose to engage, it offered several implementation options to select from. I could engage at a high level or dig into technical detail; the agent adapted either way.
A consistent minor friction: the agent frequently prompted me to run tests. When it became disruptive, pushing back usually got a response like:
“Honest answer: I could have done it two different ways without involving you, and I should have tried them first.”
I also valued the agent’s research mode (launched before committing to a detailed design when technical feasibility was uncertain) and its code review mode, which examined finished code for hidden issues even after everything was working.
Execution and Integration
The project was structured into seven phases, with the first six largely independent and a final integration phase to tie everything together. The early phases went smoothly.
The integration phase was difficult. Real-time data feeds, race conditions, complex state transitions, and timing issues made for an intense day and a half. The two major problems resolved differently: one I forced the agent to diagnose by pushing back on human-in-the-loop testing; the other I isolated myself using console messages the agent had embedded. That second issue was a subtle timing problem I’m not confident the agent could have caught on its own.
Once through integration, it was satisfying to see the application come to life. Final steps included the agent auditing the finished code against the initial requirements, followed by a pass to refresh all design documentation.
Project Stats
- 39 source files, approximately 10,000 lines of code
- 642 test cases, approximately 10,000 lines of test code
- 107 GSD artifact documents generated (plan and summary documents most significant)
- 276 git commits over the life of the project
Implications for QA when Using GSD
It’s not obvious where an independent QA role would have fit in during active development. Development was highly interactive. Rarely did ten minutes pass without a permission prompt, a design decision, a process transition, a test request, or a feedback ask. Post-development, useful QA contributions would include:
- Exploratory testing in a live data environment.
- Stress and limit testing on the data feed: fast, slow, intermittent, stalled, varying record counts and payload sizes. A formal data schema and sample data were used, but mocked streams with boundary values were not.
- Using other LLM agents to critique source code, AI-generated tests, and GSD artifacts.
- Managing beta testing with real users.
There’s also a broader question: could the agent’s testing behavior be shaped by a GSD-like framework or a set of Superpowers-style skills? Some have speculated that combining Superpowers’ skill enforcement with GSD’s context orchestration could be the right architecture for spec-driven development, though interoperability is an open question.
Leveraging Claude for the Testing Gaps
I outlined four categories of bugs the agent was consistently missing. The following are Claude’s own explanations and remedies, edited for length.
Bugs Obvious from Prior State
This is a coverage problem and the most fixable. Generated tests check states in isolation (clean fixture, one action, assert, teardown). State-sequence bugs live at the A→B→C interaction that no isolated case reproduces.
Two fixes include:
- Drive test generation from user journeys and session scripts rather than per-feature acceptance criteria; explicitly instruct the agent to carry state forward across steps.
- For anything stateful, supply a state model and request model-based testing that walks transitions and asserts invariants at every reachable state. The spec describes intended per-feature behavior; emergent bugs require journey context that must be supplied explicitly.
Transitory UI Issues (Jitter on Rotation)
This had the worst automation ROI of the four. A single screenshot cannot detect jitter (it’s a timing artifact, not a state). The right approach is to reduce it to determinism: freeze the clock (mock requestAnimationFrame or the time source), step the animation manually, and assert object position at known timesteps. If the glitch is genuinely sub-perceptual, Playwright traces with frame-diffing can flag unexpected position deltas, but this category often stays human-in-the-loop, and that’s appropriate.
Aesthetic and Layout Issues
This splits into two problems:
The objective half (did layout drift unexpectedly?) is a visual regression baseline problem (Playwright toHaveScreenshot, or Percy/Chromatic). It flags change against a known-good baseline without judging design quality.
The subjective half: the agent handles this reasonably well as an explicit design-audit step. Feed it a rendered screenshot and ask for critique against the design system (spacing scale, max content width, hierarchy, and contrast). The more aesthetics are encoded as constraints, the more “balance” becomes a testable assertion. The agent will not volunteer this critique during functional test runs; it must be a separate pass.
End-to-End Bugs at Integration Points
These should be caught, so the interesting question is why they aren’t. I almost always noted one of two causes: either the tests mock the endpoint (spec-driven frameworks favor stubs), so the bug lives in the seam between mock and reality; or happy-path bias—the agent tests the documented success path and skips timeouts, 500s, malformed payloads, expired auth, and partial data.
Fixes include: add contract tests; run a test tier against a real or recorded endpoint to assert against real response shapes; and explicitly instruct the agent to enumerate failure modes per integration point, not just the success case. Given that instruction, it does fine.
Let’s build the best program for your needs
Tell us about your program challenges and gaps and we’ll get right back to you.
