2026.07.05

The Importance of Rituals

This weekend brought access to Claude Fable, and I had to know: what did it think of the codebase for Found? As someone who started the game with little knowledge of game development and no understanding of GDScript, I was mildly terrified of the AI’s judgement. Fable came back with: The architecture is coherent and the big tradeoffs are sound and now well-documented.

Quite a compliment for a model and a prompt that were all business and no sycophancy.

When I began building Found, I was documenting architecture in Figma, had no idea how to use classes (despite Godot giving me plenty of them), and most major systems were cobbled together from a smattering of tutorials, many still from Godot 3. In game terms – I wasn’t as leveled up as I needed to be for the quest ahead.

I’ve been a part of enough large-scale software projects to know the risks of letting beginner decisions define the limitations (and the stability) of the end product. I knew I needed rituals to protect the game from my novice level.

One: Refactor Fridays

For the first nine months of development, I spent my Fridays doing nothing but refactoring. Every Friday, I revisited the code: cleaning, documenting, renaming things once I finally understood what they were, and trying to make sure past me wasn’t quietly mopping future me into architectural corners. This was not glamorous work, but I looked forward to it, because every weekend ended with a more thorough understanding of the system I was building.

A diagram showing early relationships of nodes in the game Found.
I started diagramming and documenting early, both so I wouldn't forget it later and so that I would remember it in the moment.

Two: Documentation

Found has always had a lot of invisible structure. I carefully documented, not like a developer, but like a designer. I have entire files capturing characters and conversation trackers, levels and world events, enemies and boss sequences – each created with every new level and checked at every world zone. I did this on my own, without AI, and the creation of the very-visual documentation allowed me to commit ridiculous amounts of complexity to memory. Later, when I finally did allow AI into the codebase, the first thing I had it do was documentation. I wouldn’t allow it to do more unless I could be sure we were aligned.

Three: Careful AI Use

When I started, I used AI mostly as a tutor. I asked for explanations, examples, and help finding my way through problems that Stack Overflow wasn’t sufficient to help me solve. It wrote snippets of code, but never more. I needed to understand enough to know whether the answer was useful or just plain wrong, and having the work done for me wouldn’t allow me to build that instinct.

Later, as the game became more stable, I started using AI differently. I used it to audit, to find weaknesses and to identify performance opportunities. Then we worked together to clean things up. At first I reviewed line-by-line to understand what changes were being made. I continued to learn. Then, once I felt things were stable, I allowed Claude to write entire quests for me. I still kept it in a sandbox, with careful prompting and testing, all of which was made possible thanks to a careful and consistent architecture.

At the end of its assessment, Fable offered one final, backhanded compliment: The through-line: this codebase’s ADRs consistently chose explicit and simple over automatic and safe — a good choice for a solo-authored project…

So while the rituals worked, the system is still too reliant on me, my memory, and my ability to notice when something drifts away from intention. Which is a final thing to fix before moving into playtesting.