Feeling The Stones As We Cross The River
4/15/2026
Lately I’ve been experimenting with some of the repos that are meant to augment tools like Cursor. The idea is simple: if AI can already write most of your code, maybe the real leverage is in structuring how you work with the AI.
One of the main ones I tried was Get Shit Done (GSD): https://github.com/gsd-build/get-shit-done
At a glance, it’s exactly the kind of thing that should make you more effective. It sits between you and the model, forces you to think in phases, asks product-level questions, and tries to make sure you actually understand what you’re building before you start building it.
And to be clear, it does that really well. But I ended up walking away from it. Not because it’s bad. Because my project didn’t fit it.
Right now I’m working on an AI-driven role-playing game where the AI acts as the Dungeon Master. The whole point of the system is that it can generate stories dynamically, respond to the player, and create something that actually feels like a real tabletop experience.
There isn’t a clear reference product. There isn’t a standard UX. There isn’t even a clear definition of what “good” looks like yet. A lot of it is just a feeling I’m chasing. I’ll know it when I see it.
Still, I went into this thinking a structured system like GSD might help. I already use AI heavily when I code, and one of the biggest problems I run into isn’t that the AI can’t build something. It’s that I haven’t thought the feature through well enough, so it builds something that technically works but isn’t what I actually needed.
So the idea was: maybe if I force more structure upfront, I can avoid that. Maybe I can think more clearly, define things better, and stop sending myself down rabbit holes. And I was confident that's what was happening.
GSD pushed me to break things into phases. It asked good questions. It forced me to think about dependencies in a way I normally have to manually prompt for. It didn’t feel like fake enterprise process either. There was no ceremony, no pretending I was running a sprint. Just a straightforward attempt to make sure the plan made sense before execution.
Things started not going my way though fairly soon.
Because that’s what actually happens when you build something like this: you change your mind.
Early on, I had designed the system around characters. You create a character, and then you play the game. Simple enough.
Then at some point I stopped and thought, “Wait, that doesn’t make sense.” Characters shouldn’t be locked into a single run. They should exist across different campaigns. The campaign should be the core unit, not the character. So I flipped it.
Now campaigns come first, and characters live inside them but aren’t tied down to just one.
That’s not a small tweak. That’s a foundational change. It affects everything: the data model, the flow, the UI, the assumptions behind future features.
And once that shift happened, the carefully structured phases started to feel… off.
And that’s where things got slow.
Instead of just moving forward, I found myself reworking the plan, re-validating decisions, revisiting things I had already built. It felt like I was doing the same thinking twice, not because it was necessary, but because the system wanted to stay internally consistent.
GSD had this underlying assumption you had a product in mind. Yes it asks great product questions as you move along, even some questions I hadn't anticipated, but on some level you knew what you wanted.
The clearest example of this came from the UI.
Originally, I had a clean layout in mind. Story on the left, DM chat on the right. It made sense. It was easy to reason about. You could plan it out, implement it, move on.
It broke immersion. It felt like I was talking to a chatbot about a story instead of being inside the story.
So I scrapped it and rebuilt it. Now the story flows in a single view, and the DM appears inline, almost like a character, then disappears again. It’s a small change on paper, but a big one in terms of feel.
There’s no way I could have planned that correctly upfront. I had to experience the wrong version first.
After that, I stopped trying to force the structure.
I went back to using Cursor in a much more freeform way, but not in a sloppy way. The difference was in the loop.
Instead of planning everything out, I started moving in tight cycles. I’d build something quickly, run it, play with it, and pay attention to what felt off. If something was weird or annoying or just didn’t match what I had in my head, I’d write it down and adjust.
Over and over.
Some of what I built got thrown away. Some of it got reworked. But each pass got me closer to something that actually felt right.
And the important part is this: I didn’t know what I wanted until I saw what I didn’t want.
Now, someone could push back on this and say I should have planned more upfront. And for a lot of software, that’s absolutely true.
If you’re building a budgeting app or a dashboard or even a clone of something that already exists, you can get pretty far with good planning. The patterns are known. The expectations are clear. This wasn't one of those projects.
This was part game design, part AI behavior design, part experience design. The core value wasn’t just whether something worked. It was whether it felt right. That isn't going to be known until you use it.
What this experience really drove home for me is that tools like GSD are powerful, but they assume something that isn’t always true: that you already understand the problem you’re solving.
When that’s the case, structure is a force multiplier. It keeps you organized, consistent, and efficient.
But when you’re still figuring things out, that same structure can become friction. It locks in assumptions too early and makes it harder to change direction when you learn something new.
So if someone asked me whether they should use something like GSD with Cursor, my answer would be simple:
Yes, but only if you already understand the problem.
If you’re still exploring, it’s probably going to slow you down.
Use it when you’re executing, not when you’re discovering.
AI has changed the economics of building software in a pretty fundamental way. Spinning up an idea no longer takes hours or days. It takes minutes. Which means throwing something away isn’t the same kind of loss it used to be. It’s just part of the process.
And for certain kinds of problems, especially the fuzzy ones, the only way forward is to move, look, adjust, and move again.
You can plan where the river is.
But if you actually want to cross it, you still have to feel the stones.