How GSD Tackles Context Rot When Building Projects With Claude

Working with language models on existing codebases has generally proven more reliable than attempting to generate complete projects from the ground up. When developers ask Claude to build something substantial through what might be called "vibe coding," the results frequently disappoint. The AI may lose sight of earlier specifications or exhaust tokens cycling through unproductive patterns, despite genuine effort.

The challenge of "context rot"—where an AI's attention weakens as it processes longer sequences—deserves examination. While this represents more of a workaround than a fundamental fix for current LLM limitations, the problem is very real.

The foundational "Attention is all you need" paper shaped how researchers built modern language models, enabling them to process meaning and approximate understanding of grammar. Yet empirical work reveals that tokens appearing early in a sequence receive more focus than those appearing later, regardless of context window size. This creates the rot effect.

For typical brief queries, this presents no practical difficulty. Extended projects, however, trigger what researchers term "attention dilution"—as though the model's focus wanes like a tired child. One approach involves breaking larger problems into smaller subtasks distributed among specialized agents while preserving the broader context.

Understanding GSD

GSD implements a meta-programming layer—what developers call context engineering—positioned above Claude. While comparable to earlier specification-driven systems like AWS's Kiro, the implementation differs meaningfully.

The tool combats context rot by layering an internal task planning framework atop Claude Code's existing subtask capabilities. Testing this approach requires attempting an actual project.

Overly complex undertakings simply consume tokens without generating value, as discussed in previous coverage of Claude Cowork. A more modest goal—building a front end for browsing JSON objects by identifier as though accessing a database—provides a suitable test case. The specific interface design remains unspecified initially.

Installation and Initial Planning

Launching Claude from a terminal and executing the command /gsd:new -project initiates the process. (This assumes Claude Pro rather than an API subscription.)

Once GSD assesses the starting conditions, it begins a structured interrogation. A green progress indicator appears at the bottom of the interface. The tool initializes a git repository and prepares for conversation based on the initial project description, however imprecise.

The eventual outcome depends heavily on response quality to GSD's questions. While generally well-targeted, the volume of inquiries is substantial.

The questioning starts by identifying the intended audience—much as one would when launching any product. In this scenario, the answer points toward colleagues as users.

A subsequent question about the problem being solved proved unexpected. The response involved multiple considerations, though technically the first option applied: preventing colleagues from directly manipulating JSON files. The next inquiry proved equally incisive. The initial deliberate vagueness was being systematically challenged.

The question of whether users would modify data had not been explicitly addressed. While editing capability would enhance utility, it would also expand scope. Yet including this feature seemed justified.

Though the original description used the word "search" rather than "viewing," GSD recognized the underlying intent. This demonstrates how the tool distinguishes between requirements, implementation phases, and broader strategy.

After discussing object types, approximate quantities, and search mechanics, the conversation turned to platform selection. The addition of editing capability—requiring management of inconsistent file formats—pointed toward a desktop application. GSD suggested a web-based solution, which would make sense for a view-only tool.

At this stage, the interaction mirrored what a competent designer would ask of a manager presenting an unrefined concept.

A multi-select question about operations touched on CRUD principles indirectly. The target operating system was narrowed to macOS for practical reasons.

One final planning question proved particularly revealing, underscoring the importance of designing toward a concrete purpose. Ensuring colleagues would actually use the application remained paramount.

GSD generated a PROJECT.md file and began consuming tokens. The green progress indicator remained below 30%, which was notable. The tool committed its own project and metadata files and continued. Running in non-interactive mode with "quick" planning selected, parallel planning work proceeded.

The structured questioning process did prompt deeper consideration of actual requirements. Research options were skipped in favor of moving directly to implementation planning. Verification steps, though recommended and token-intensive, were deferred.

The planning configuration ultimately included these elements:

• Version 1 defined as a viewer with standard viewing capabilities
• No editing functionality in the initial release
• A reasonable set of v1 requirements established

Manual development from this point might have progressed further already, but this reflects the developer's eternal tension. Unstructured human coding proves no more sensible than allowing an AI to proceed without direction. Though a roadmap was initially declined, GSD generated one regardless, including phases, objectives, requirements, success criteria, and verification procedures.

Progress remained around one-third complete, though additional documentation files had accumulated. GSD distributed attention across different stages, building a web of interconnected documentation derived from the responses provided.

The execution phase finally commenced. SwiftUI was selected as the implementation framework, which proved acceptable. Numerous files were generated. At this point, the exploration pauses. While Swift was unfamiliar, the model's purpose—handling direction and planning rather than execution—remained clear.

Conclusion

Claude, operating through GSD, demonstrated capacity for thorough project planning, extracting logical steps from an intentionally vague starting point. The distinction lies in how GSD manages this planning structure—it emerges from the tool's logic rather than explicit user definition.

Guiding the process required understanding how planning functions, yet the questions remained product-focused. Neither party explicitly discussed design concepts like CRUD, and the target implementation platform was never directly specified.

The next examination will evaluate the SwiftUI application GSD produced and assess its actual performance.

Source: The New Stack