Allgemein

How GSD turns Claude into a self-steering developer

Von [email protected] Loading...
How GSD turns Claude into a self-steering developer

A vibrant, pop-art style illustration of a person sitting at a computer desk wearing headphones and leaning back. A large, stylized blue hand emerges directly from the computer monitor, pointing a finger toward the person’s forehead. The scene features a bright pink background with a Wi-Fi symbol floating above the person’s head and small yellow digital blocks scattered in the air.

The speed at which ClawdBot MoltBot OpenClaw climbed in popularity was quite phenomenal, and for good reason: It has an audience beyond the developer space, especially those who just want to experiment with digital assistance. Todays post continues my journey with GSD, but the LLM agent landscape is changing rapidly and this shooting star caught everyone’s eye.

At its core, OpenClaw is a locally hosted, open-source AI assistant that runs on your computer or server. You talk to it through apps you probably already use, like WhatsApp, Telegram, Discord, Slack, Signal, or even iMessage. And it really “does stuff” — sometimes too well. It is a gateway service that maintains WebSocket connections and includes a smart orchestration layer for working with LLM agents.

OpenClaw shows a strong technical focus on LLM agents; however, its significant and varied security issues mean we must think more carefully about agent vulnerabilities before experimenting with them. But keep watching, even the odd sidetrack of the AI church is genuinely intriguing. OpenClaw may be flawed, but it does show how laughably limited the available and entrenched digital assistants are compared to what agents can do. Now back to our scheduled program.

OpenClaw may be flawed, but it does show how laughably limited the available and entrenched digital assistants are compared to what agents can do.

In my first article on the popular Claude extension GSD, I set up a project to create a JSON viewer. GSD then asked many questions to create concrete plans before finally crunching a version 1 on its chosen platform, SwiftUI.

It had just presented its work when we stopped:

So first of all, let’s run the actual thing. I am following the advice carefully, as I am not a SwiftUI developer and I don’t use Xcode. Indeed, I had to get the update to 26.2 just to use it. I run it, and indeed it does what is described:

So I approve the checkpoint. Yes, it’s just a titled window, but it tells me that all the assumptions are correct. It spends some time updating the roadmap and requirements.

And then we were ready for a second planning phase:

Well, that percentage progress is creeping up. At the time, I thought it represented how close the project was to finishing.

I am running GSD within a Warp shell, but one downside of running in a single continuous session is that I can’t use Warp’s distinctive command-and-response blocks, which would give me the times of all the responses.

The phase goals and success criteria now roll into SwiftUI specifics, which I like. While I’m not a Mac developer, I can see that it is pulling in the common components it needs to operate:

Despite my managerial role in this process, my developer head can follow the steps it is working through. After creating the plan, it executes it.

The human (that is, me) is now required again for verification – this time to check I can load a JSON file through the app:

I do indeed load a JSON file from my project with the expected Mac user interface, and it does count up all the objects within the file – and no more. I approve its progress in order to continue. Just before I do, I ask a quick question regarding token usage:

Again, GSD wants my approval before continuing. I give it.

And finally, we hit my plan limit:

So I clear the context window and attempt phase 3 again. Note the scary skull as the progress bar goes red.

Anyway, now I know what that progress bar means! It resets when the window is clear. I also check my billing on the website. I am also warned that I am approaching my limit until the periodic reset:

This is on the Pro plan, by the way. So I execute phase 3. For the record, here is the planning section:

After waiting for my tokens to refill from the magic fountain Pro plan usage, we plough onwards. Now, GSD was working out how to implement a browsable list, bound to my JSON data.

Finally, GSD crunched a much more significant version, with much of the viewing capabilities apparently in place:

And after firing up the app in Xcode, I can select objects at will from the JSON file I selected:

For completion, here is the functional layout of the generated project within Xcode. The structure looks fine — and I’ve no problem continuing with this project. But we’ve gone far enough to prove GSD has what it takes to steer a development project without issue.

Conclusion

While the GSD workflow uses a blizzard of organizational terminology — plans, requirements, phases, waves, checkpoints (they really didn’t leave any agile jargon behind) — I understand this is meant to tie everything together, retain “focus,” and put less pressure on the context window.

And I was able to continue after running out of the window, running out of tokens, and the Mac having to restart. As I mentioned in the previous article, these restrictions are of their time — given the amount of global resources apparently now going towards AI infrastructure, I expect token costs to come down and the average context window to expand until it presents no restrictions. If I wanted to avoid the break between token refills, then I would have needed to upgrade my plan.

For a developer, seeing the project develop requirement by requirement is perfectly natural — but this might be slower than some imagined. For me, the value lies in pursuing a project whose language (SwiftUI) I can learn after seeing a working prototype. I feel GSD is a sensible route forward that I expect Anthropic will quietly absorb.

The post How GSD turns Claude into a self-steering developer appeared first on The New Stack.