Working with LLM tools on greenfield projects has historically proven problematic. When developers attempt to build substantial applications from the ground up using agentic systems like Claude, the results frequently disappoint, even when the model works diligently. The underlying issue: the LLM either misplaces critical details or consumes tokens cycling through repetitive, unproductive patterns.
This phenomenon, known as context rot, deserves examination through the lens of GSD, a widely adopted Claude extension designed to mitigate the problem. While addressing context rot represents a workaround rather than a fundamental fix—reflecting current limitations in LLM architecture—it remains a practical concern worth understanding.
The foundational paper "Attention is all you need" established the transformer-based approach that powers modern LLMs, enabling them to process meaning and replicate syntactic comprehension. However, research indicates that tokens appearing earlier in a sequence receive disproportionate attention compared to later ones, regardless of context window size. This imbalance creates the degradation effect.
Short prompts rarely encounter this limitation. Extended tasks, however, trigger what researchers term "attention dilution"—as though the model's focus wanes like a distracted child. One solution involves fragmenting complex problems into discrete subtasks distributed among specialized agents while preserving overall context coherence.
Understanding GSD
GSD implements a meta-programming layer—described as context engineering—positioned atop Claude. While superficially resembling earlier specification-driven systems like AWS's Kiro, the approach differs meaningfully. GSD combats context rot through an internal task planning framework that leverages Claude Code's existing sub-task capabilities.
Overly ambitious undertakings inevitably become token-burning exercises. For testing purposes, a modest scope proved sensible: constructing a frontend for browsing JSON objects by identifier, mimicking database functionality. The JSON structure itself would be provided if needed, with frontend technology left unspecified.
Installation and Initial Planning
After launching Claude from a Warp terminal within the project directory, the command /gsd:new -project initiated the process. (This workflow uses Claude Pro rather than an API subscription.) Once GSD assessed initial conditions, an interrogation phase commenced, marked by a green progress indicator tracking advancement toward completion. The system established a git repository, leaving only the task of formally defining the project scope—deliberately vague but sufficient for productive dialogue.
Project quality hinges directly on response caliber to GSD's questions. While largely appropriate, the volume proves substantial. The system first investigates the intended audience, much as any product launch would. In this instance, the answer aligned with the first suggested option: colleagues. The subsequent inquiry proved unexpected, exploring the primary problem the application would solve. The answer combined multiple considerations, though technically the first option sufficed: preventing colleagues from manipulating JSON files directly. GSD's follow-up demonstrated precise targeting, dismantling the initial deliberate vagueness.
The original specification never explicitly addressed whether users could modify data. While adding this capability seemed reasonable, it would substantially expand scope. Nevertheless, including it as a requirement felt justified. GSD intelligently inferred concerns from the stated goal of "search," distinguishing between requirements, implementation phases, and broader planning considerations.
After clarifying object types, approximate quantities, and search mechanics, platform selection emerged as the next decision point. Since the requirement for editing functionality introduced the need to manage inconsistent file formats, a desktop application became the logical choice. GSD had recommended a web application, which would certainly make sense if viewing alone were the goal. At this stage, the interaction mirrored what a competent designer would extract from a manager presenting an unrefined concept.
A multi-select question indirectly addressed CRUD operations. For practical usability, macOS was designated as the target operating system. One particularly revealing planning question underscored the importance of defining product purpose with clarity: ensuring colleagues actually use the application remained paramount.
GSD generated a PROJECT.md file and commenced token consumption. The green progress indicator remained below 30%, a notable observation. The system committed its own project and metadata files, then continued. Selecting "quick" planning and allowing parallel work, the process ran non-interactively. No research phases were selected, focusing exclusively on implementation derived from planning. Verification steps, though recommended and more thorough, were skipped to conserve tokens.
The planning configuration ultimately included these elements: project scope, audience, primary problem, data modification capability, object types and quantities, search mechanics, platform selection, target OS, and success metrics. This structured approach prompted deeper reflection on actual requirements—a definite benefit. Whether starting from scratch manually would have progressed further by this point remains debatable, though the developer's dilemma persists: human vibe coding proves no more sensible than delegating to an LLM.
GSD subsequently created a version 1 plan focused on viewing functionality with standard display operations—no editing required. This yielded a coherent set of v1 requirements. Though a roadmap was initially declined, GSD generated one regardless, incorporating phases, objectives, requirements, success criteria, and verification procedures. Progress remained around one-third complete, with additional documentation files now in place.
GSD distributes attention across different stages, constructing a documentation network derived from the responses provided. The execution phase finally commenced. SwiftUI was selected as the implementation technology, which proved acceptable. Numerous files were generated, but the examination stops here for the present. While Swift expertise is absent, this development model restricts the human role to direction and planning rather than execution.
Conclusion
Claude, operating through GSD, demonstrates capability for sophisticated project planning, extracting logical steps from imprecise specifications. The distinguishing factor: GSD itself manages the planning structure rather than the developer defining it explicitly.
Guiding the process required understanding how planning functions, yet the questions remained product-focused. Neither party explicitly discussed design patterns like CRUD, nor was the target implementation platform mentioned directly. The next installment will evaluate the SwiftUI application GSD produced and assess its actual performance.
Source: The New Stack