Log 4 – The Idiot Savant

Sub-Series: How to Train Your Bot (Part 1 of 4)

In Log 3, I talked about the Gulf of Evaluation—the difficulty of knowing the state of the system. But now I face its twin, the Gulf of Execution. This is the gap between what I want the system to do and the means the system provides to do it.

Right now, that gulf is massive.

Bridging the Gulf with AI

Let’s be real: I didn’t bridge this gap by writing boilerplate code by hand. That is the old way. I leveraged the very thing I am trying to build.

I used Kiro, Gemini, ChatGPT, and Perplexity. I treated them as my team of engineers. I used them to brainstorm, to generate the Kubernetes manifests, debug the Python syntax, and explain the obscure error messages. I stopped thinking about the syntax of the bridge and focused entirely on the architecture.

By leaning on these tools, I condensed weeks of frustration into few days

We have spent the last few logs building the temple. We racked the DGX Sparks, wrestled the Kubernetes networking into submission, and locked down the security. The infrastructure is beautiful. It’s a Ferrari with the engine idling. But a Ferrari sitting in a garage isn’t a race car; it’s just expensive furniture.

Now, I turn the key.

This marks the start of a new phase. I’m moving from Hardware & Orchestration to Applied Machine Learning. I’m following the roadmap from Deep Learning and the Game of Go by Kevin Ferguson and Max Pumperla (https://amzn.to/49t64uQ), but I’m doing it my way: inside a sovereign, containerized, GPU-accelerated cluster.

Defining the Universe

To cross the gulf, I first had to define the laws of physics for this new universe. Therefore before you can train an AI to dominate a world, you first have to create that world.

In design terms, the rules of Go are constraints. They tell the agent what is possible. I had to code the concept of "Liberties" (the empty points that allow a stone to breathe) and "Capture" (what happens when those liberties vanish). I had to strictly define "Ko"—the rule that prevents the game from entering an infinite loop.

If I get this wrong, the "System Image" fails. The bot will try to do things that physics doesn't allow, and the gulf will widen again.

This isn't AI. This is just the plumbing. It’s the digital equivalent of gravity.

Meet the "Agent" (The Idiot Savant)

Once the physics were working, I wrote my first bot.

In the industry, we use fancy terms like "Agent" or "Actor." It implies intelligence. It implies intent.

My agent is... well, it’s an idiot.

I implemented what is effectively a Random Bot. It looks at the board, asks the physics engine, "What moves are legal?" and then rolls a virtual die.

It has no strategy. It has no fear. It has no desire to win. It just does.

I set it loose on the 9x9 board, running on the most advanced consumer grade silicon NVIDIA has ever produced. It placed stones with the confidence of a grandmaster and the logic of a goldfish.

The Problem with Random

Watching two Random Bots play against each other is a surreal experience. Because they don't understand the concept of "territory" or "winning," they don't know when to stop.

Humans stop playing when the boundaries are clear. We look at the board, nod to our opponent, and say, "Okay, that's your territory."

This bot? It’s stubborn. It keeps placing stones until literally every legal spot on the board is filled. It will fill in its own eyes. It will kill its own groups. It plays until the game collapses under the weight of its own absurdity.

Why This Matters (The "Sovereign" Flex)

You might ask: "Why did you buy two DGX Spark nodes and build a Kubernetes cluster just to run a random number generator?"

That’s a fair question. I could run this Random Bot on a Raspberry Pi. I could have just installed Python directly on the metal and been done with it.

But here is the difference: Architecture.

I didn't just write a script. I deployed a System.

I’m not running this locally on my laptop; I’m running it as a defined job in a namespace. My code is decoupled from the hardware. Today, the "Brain" block of my system is a simple random function. Tomorrow, I can swap that block out for a Deep Neural Network, and the rest of the pipeline—the board state, the game rules, the scoring engine—doesn't need to change.

This is what sets this design apart from just using the Spark out of the box. I have laid the foundation for a Multi-Agent System. I can spin up fifty of these bots in parallel containers, have them play a thousand games in seconds, and aggregate the results. The DGX isn't sweating yet, but the plumbing is ready for the flood.

The Baseline

This Random Bot is terrible, but it is crucial. It gives me a Baseline.

Right now, my win rate is 50/50 (because it’s random vs. random). This is the floor. Everything I do from this point on—every neural network I design, every reinforcement learning loop I run—has to beat this idiot.

The engine is started. The physics work. The bot is alive, even if it is completely mindless.

Next Log: We stop rolling dice. We give the bot some lessons. We start feeding it human games and teaching it to mimic the masters. We enter the world of Machine Learning, Tree Search algorithms, which are essential tools in game AI and all kinds of optimization problems. Deep Learning, Neural Networks, Reinforcement Learning! Are you excited?!