Until now, I’ve generally only used LLM tools with existing projects. Attempts to create detailed projects from scratch via agentic LLMs like Claude with “vibe coding” often fail, despite the earnest efforts of the LLM. It often forgets information or burns tokens running in a non-productive loop.

In this post, I’ll look at the popular Claude extension GSD, and how it works to defeat context rot.

Something rotten in the state of LLMs

It is important to differentiate between trends that are genuine improvements on a pattern and those that are just getting around current restrictions. Dealing with “context rot” is the latter, so it shouldn’t be considered anything more than a temporary workaround reflecting LLM technology as it exists at the moment. But it definitely exists.

The now-famous paper “Attention is all you need” has guided researchers towards LLMs that manage to work their way through meaning and emulate an understanding of sentence structure. But research does suggest that earlier tokens get more attention than later ones, whatever the size of the context window. Hence, we get rot.

For the usual short prompts, this is no issue at all. But for lengthier tasks, the research notes “attention dilution”, as if the LLM is a bored 6-year-old. One answer to this is to split problems up into tasks for sub-agents to consume, and yet somehow keep the overall context intact.

So what is GSD?

GSD (I’ll stick with the acronym for this post) adds some meta-programming (described as a context engineering layer) on top of Claude. I’ve looked at one of the earlier spec-driven systems, AWS’s Kiro, but this isn’t quite the same.

GSD fights the context rot problem by providing an internal task planning framework with judicious use of sub-tasks that already exist in Claude Code. I’ll attempt a small project with it and see how we do.

As I described in the article about Claude Cowork, overly ambitious projects will just end up as a bonfire of tokens. So I’ll stick to what I often ask for — a front end for viewing a set of JSON objects via ID as if they were a database. If asked, I’ll provide the JSON templates. I won’t specify a particular front end.

Installing and planning

I installed GSD via npx:

👁 Image

Then I started Claude in that directory from my Warp terminal:

👁 Image

And then used /gsd:new -project. (Note I’m using Claude Pro, not an API plan.)

👁 Image

And then after GSD examines its start conditions, the questioning begins:

👁 Image

Note the green percentage progress meter at the bottom, which I assume moves towards completion. GSD starts a git repository — so all that remains is for me to do is to define the project as I have above. It is vague, but enough to start a conversation with.

The quality of the project will now obviously hinge on the quality of my responses to GSDs questions. They are largely the right questions, but there are many:

👁 Image

First, it explores who the audience is — much like the release of any product. However, in this case, the answer is exactly the first option above. This is for colleagues.

I wasn’t actually expecting the next question:

👁 Image

The answer is a mixture of things, but technically it may as well be the first answer; I want to avoid colleagues working directly with JSON files. Again, the next question is very well targeted. My initial purposeful vagueness is being carefully skewered:

👁 Image

I didn’t mention whether users would need to edit the data. That would obviously be good, but might extend the project quite a bit. Yet it feels reasonable to set that as an expectation. Ok.

👁 Image

So while I never explicitly stated the app was for viewing (I used the term “search”), GSD intelligently picked up on my concerns. This is how GSD differentiates between requirements, phases, and overall planning.

After describing the type of objects, and the rough number, and how the search begins, we came to the question of which platform to target. Because I added the overall requirement for editing, thus the need to work with a set of inconsistent files, I went for a desktop app. It recommended a Web app, which I would certainly agree with if it were just for viewing.

So far, all I have done is answer the same type of questions that a sensible designer would ask of a manager who woke up one morning with an idea he couldn’t implement himself.

The first multi-select question was also (indirectly) about CRUD:

👁 Image

For ease of use, I also fixed the target OS to macOS.

I was deeply amused by one of the last planning questions:

👁 Image

This underlines the principle of planning a product with a known purpose. That my colleagues use the app is always at a premium.

It created a PROJECT.md file and the tokens started to be burned, as expected. That green percentage row/dial seemed still to be under 30%, which was interesting. It committed its own project and meta files and continued. I let it work “YOLO” (i.e. non-interactively) and chose “quick” planning. I also let it work on plans in parallel.

If you’re about to ask whether this process made me think harder about what I actually needed, the answer is a definite yes.” I chose no research options, just for implementation from planning. I also didn’t bother with verification steps. These were recommended but would use many more tokens.

In summary, we have this for a planning configuration:

👁 Image

It then created a plan for version 1, which I defined as just a viewer, with all the basic viewing functions as expected. No editing needed. So we reached a fair set of v1 requirements:

👁 Image

It could also be said that if I just started doing this myself, I would be a good way through it by now, but this is the developer’s dilemma. Human vibe coding is no more sensible than letting an LLM do it. I think I initially refused a roadmap, but I think GSD ignored me and produced one anyway:

👁 Image

So it created a simple roadmap along with phases, goals, requirements, criteria, and verification steps. Progress is still only a third, but we now have more files.

GSD throws attention between the different stages, creating a network of documentation based on what it gleaned from my answers.

We finally got to an execution phase.

👁 Image

It chose to use SwiftUI, which was fine. And lots of files were created. But we’ll stop here for this week. I’ve never used Swift, but part of the point of this form of coding is that my job is limited to direction and planning, not execution.

Here is what was built, with verification steps. We’ll examine this next week.

👁 Image

Conclusion

We’ve seen that Claude, via GSD, is capable of detailed project planning, extracting sensible steps from a vague project. What is a little different is that this planning structure is managed directly by GSD — they were not defined by me.

Now, in order to drive the process, I did have to understand how planning works, but the questions were definitely “product” centred. Neither of us mentioned design principles such as CRUD directly, and I never discussed the target implementation platform explicitly.

In my next post, we’ll look at the SwiftUI application that GSD just cooked up and see how it performs.