Three Months Catching Up to the Speed of AI
Overbuilding, accidental RAG, a memory tree called Santa, and the game I finally built after three years.
I first tried to build this game in early 2023. Best I ever got was a Unity 1-level demo, and then a year and a half later, a similarly unworthy prototype in Godot. The version you can play now is a 12-level demo that was legitimately fun and replayable after just over a week of development.
Starting Down the Hill, May 2026
After being laid off, I took an extended break from tech, working on myself while waiting for the dust to settle on a rapidly changing job market. Gaming, TV, self-improvement videos, and even the exploits of Carl and Donut eventually got old, so I thought, hey, why not learn something about AI? It didn't take too many chats and YouTube videos before I was competently prompting AI to walk me through building something by hand. I even bought an annual Claude Pro subscription on May 3. On May 5, I upgraded to Max 20x.
The ride I've been on since has been as exciting as it's been fraught, carrying my learning along at a pace I've never before seen. I've had the opportunity to work and play with technologies that are utterly mind-blowing, even for a software engineer committed to scientific rigor. And something changes every. single. day. It's candy for my brain.
I've been in the software industry a while. Back in my humble beginnings, I was fixing the Y2K issue on AI software of a different sort, related to animal husbandry (Shoutout Nick M). In the years since, I've gradually migrated further and further from end users, first with RESTful services and microservices, then into Kubernetes and cloud computing as my roles became increasingly operational. And through all those transitions, I kept the same mantra: automate myself out of a job, so I could move on to a more fun, novel job made possible by the automation. That might have worked a little too well...
Moguls, Yuck, June 2026
I started with one project, one GitHub repo, and built it out, integrating with Jira because it's what I knew. I used GitHub Actions for builds because it's what I knew, and I was already using GitHub. It's all just stuff I could handle pretty much blindfolded, not that I was doing much of the typing thanks to Claude Code. So I built a project idea I'd been sitting on for a while — I finally had the tools for the parts I don't do well, or that never spark my creative motivation. It was really cool, all the different things that I could now build. And so I did build... all of them.
By the time I got that first project to a state I felt I could call it "done" as a learning exercise, I had at least four new ideas I wanted to pursue. All at once, of course. And as a good engineer, I gave each project solid isolation by putting them in separate GitHub repositories. Then I started noticing the same gripes coming up over and over in my Claude Code sessions. I'd fix something in one project and it would pop up in another. And another. And so Engineer Brain kicked in and said, "I know how to solve this."
So there I was, presented with the greatest automation tool I'd ever seen... I could literally build any app I wanted.
What was that automation tool? You guessed it! GitHub Actions!
Enter the "Rules Distributor For Rules Distribution System", known affectionately as "The Complicator 4.2.42". Any time the global rules file got updated, a bunch of GitHub Actions would fire and every repo would pull in the new copy. Eleven repos, all kept in sync. Engineer Brain was very pleased with Engineer Brain.
Gathering Momentum, June 2026
Now here's where it starts to get fun...
By this point I had been watching a bunch more Claude Fable 5 demos and was like, "Ooh! What can I explore with this thing?" Some of the use cases people had come up with were ways to introspect on how you work. So I built one — a tool to analyze my own sessions. I called it "Prism."
I extracted all of my Claude Code sessions, both in the cloud and locally. Then all of my Claude chat sessions. Then I found other examples of my writing and storytelling, how I speak, and how I think. I also had a look at my repos and at Jira, and ingested everything into a Postgres database, using a local embedding model to produce vectors for semantic search.
Pro tip: connecting a chat agent to an embedding model is... weird. I highly recommend it.
And to be clear, I built all this with a goal of finding patterns in how I think and work and identifying opportunities to improve. And it worked for that.
It was one of the coolest things I've built, in terms of what I learned about myself from it.
But it was also something else.
An astute observer might now be yelling, "Did this guy just accidentally create a RAG system?"
Yeah, basically.
But honestly, the introspection was way more interesting to me than reinventing the wheel without knowing what a wheel looked like.
Reading the Terrain, June 2026
One of the analyses clustered my complaints to the models across sessions, looking for things I kept telling Claude over and over. One cluster it found, to the surprise of absolutely not me: some version of "one question at a time, please" or "Please give me one thing at a time in summary with clear highlights blah blah and I'll ask for more detail if I need it blah." Walls of text and my brain do not get along, even when I'm writing them. AI models, on the other hand, are trained to be thorough, and thorough usually arrives as ten paragraphs where nothing is highlighted and everything appears equally important. So a lot of my "suggestions" are just me telling them to STFU in gentler terms. It showed up in five different phrasings across five different sessions. I knew I'd been saying it constantly. But there's a difference between knowing you repeat yourself and having a database hand you the receipts. Engineer Brain: "We should build a way to share rules like these—" Oh. Right.
So into the machine they went, fed into The Complicator and pushed to every repo. Without quite meaning to, I'd built a flywheel: Prism surfaced the patterns, the rules file captured them, and The Complicator delivered them everywhere I worked. A memory, a policy layer, and a distribution system, all homemade, all humming along together. That lasted until I had a model analyze my existing repos and setup. It flagged the Complicator as superfluous — already covered more cleanly by my AI-native toolchain. I eventually used those learnings to retire the Complicator in favor of the built-in agent features.
The Complicator did work, credit where due. GitHub Actions for GitHub Actions' sake. But the care and feeding was real. Integrating the Jira automation alone was a pain in the ass, and every new repo meant another round of wiring. I had spent my time building, and then babysitting, a worse version of a feature that shipped with the product.
Jira because I knew it. GitHub Actions because I knew it. Stuff I could do blindfolded. Somewhere in there is the lesson I'd keep relearning all summer: I was writing adapters to make AI fit the way I'd always worked, instead of adapting the way I work. The blindfold wasn't a flex. It was the problem.
Cliffed Out, July 2026
Early on in my AI Deep Dive, a lot of the commentary I was watching and reading centered around some of the same core ideas. Reducing token usage by being smart with context engineering, not using a ton of bloaty MCPs, avoiding hallucinations, etc. I thought, hey, maybe there's a way I can inject a memory layer in here that will do even better. And I remembered this thing from my data structures class in college: trees. What I was imagining was a self-balancing summary tree of context-dependent depths combined with a way to avoid cascading updates. I'd later be reminded that this was actually a B-epsilon (Bε) tree. Leaf nodes contain the original facts, so the underlying memory remains lossless. Branch nodes contain inherently lossy summaries of everything below them. At retrieval time, the model can ask for a broad, shallow view or a narrow, deep one, trading coverage for detail. At maximum breadth and depth, it can retrieve the entire memory, context window permitting. Let's build that! I at first called it "Santa Claude", delivering tokens to good engineers. Shortly after, I took to calling it "Project Santa".
I gave my rough idea to Claude and said, "Build this for me," and it built it. It built a nice tiered memory system with hot, warm, cool, cold levels. Quite an interesting solution... to a different problem entirely. This was not at all what I had in my head. That was lesson one.
So again, I told it what I wanted, this time in greater detail, and again, it built it. This time, lo and behold, at least it was a tree! I got to work running some benchmarks against it. What were the benchmarks we ran? Hell if I know! But my system reduced token usage by 34%. Crazy. The test cases were elaborate, but they weren't testing a remotely realistic workload. Again, Claude had built a system I had generally specified. The 34% was real, but it was like measuring a car's length and using it to predict top speed. In other words, irrelevant.
Lesson two was about the ruler, not the thing being measured. I'd never specified that the benchmarking tool be independent of the system it was testing. Some of the benchmarks ended up tangled into the system as white-box tests, resulting in messy, coupled code I wouldn't have cared to publish. The whole project needed a clean slate. New project, rebuild the most promising candidate, probe a couple of variations, including my original Bε-tree, now that I knew its name. One mildly embarrassing detail: I never actually built the full semantic variation. On paper, it was the most expensive approach, requiring embeddings on top of model-generated summaries.
This time, I kept the benchmarks separate from the system. The pilot tests finally gave me meaningful directional data. And that led to lesson three: don't keep pouring API tokens and real dollars into a test that can't prove much and won't stay valid for long. Because the pilot also showed the ceiling. Whatever tokens the tree could save would be dominated in the overall token equation by agent-harness overhead: even a perfect result from the tree would reduce total usage by less than 15%. And the problem was eroding from the other end too. Agent architectures, memory systems, context windows, and model quality were all trending fast in a direction that could erase it entirely. Whatever ground Santa stood on, the industry was reclaiming it monthly.
So Project Santa gathers dust, a story for another time if anyone ever wants to hear it. I won't call it a waste, but I wouldn't do it the same way again. What I'd change, and why, is the whole point of this post.
The Finish Line
Early in July, I finally reopened the ski game I'd twice shelved.
This time I didn't build any machinery up front. No pipelines, no memory layers, no adapters. Just going native. I pointed Claude at the repo with a variation of the "Interview Me/Interrogate Me/Grill Me" mechanic: "Ask me questions until you understand what I want, then have at it." From there it was the built-in /goal command and the core tools that ship with Claude Code. That's it. That's the whole stack.
The first rule of the interview was mine, and it was the exact rule Prism had handed me the receipts on: "Don't use those awful user experience questionnaires! I hate those. Ask me one question at a time, always." All caps, hard rule. And it held. No walls of text, no forms to fill out. One question, we talk about it, we move on.
And the questions were real design questions. Early on it asked me what collecting all three snowflakes should actually mean for finishing a level, and laid out the options: a finish line that doesn't count unless you have all three, a finish line with the snowflakes as a bonus rating, or no finish line at all — the third snowflake IS the win. Each option came with what it would do to the feel of the game. That's not a requirements doc. That's the conversation I'd have with a designer, except this one was also about to go build the answer.
Somewhere in the middle of the build I asked for a screenshot of every level, and looked at them, and heard myself say "That looks pretty cool. Gotta say." Both earlier attempts had stalled at the same wall: tedious, boring work. This time the thing on the screen matched the thing in my head — and I hadn't touched a pixel of it.
What followed was session after hours-long session: build, test, build, test. I maxed out my weekly Fable allowance three times in one week getting the first few levels right.1
What exists right now is a 12-level demo, live and ready to play, with a pile of ideas beyond that. There's a link at the bottom. Go play.
And notice what's missing from this part of the story. No Complicator. No accidental RAG. No memory trees. The project that actually got DONE is the one where I brought the least engineering to the table. The interview up front made the guardrails explicit. For the first time, I had real confidence we were building the right thing. Twice with Santa I'd learned what happens when you skip that step. This time I told it how I wanted work to be done, and then I got out of the way.
Après
So that's the run. Top to bottom, three months.
Looking back, the way I interface with AI has changed twice over this three-month journey. While the first change was obvious and intentional, I really only noticed the second in hindsight. That turned out to be the more important lesson. I started out asking it what to do, like an oracle you consult on the nonexistence of silverware. But once I really got going with Claude Code, the change was visceral. I realized how much easier it would be if I told Claude what to do instead of asking it what I should do. I eliminated the middleman and inverted the relationship, and it was then that I really got (over)building.
The second change: clear guardrails, communication up front. Specs interviewed into shape.
My engineering instincts weren't wrong. They were just misguided. And I don't count the overbuilt months as wasted. I was learning the whole time, the whole way down. But the assignment was never to make AI fit the way I'd always worked. It was to adapt the way I work. And Engineer Brain still has a job: going native.
Now I sit with a rough plan for what happens next: learning from the Flip Zone demo, sharing what I discover, aiming for some consulting projects. My mantra on automation holds, strong as ever. And the candy? Still arriving daily.
P.S. The ski game is real, and it's playable. Go get it on itch at the link below.
Flip Zone
Get Snowflakes, Catch Air
...and don't forget to collect EVERY flake.