A month ago, I opened Claude for the first time with a simple idea: make a video game. The project was called Rekall Studio. I had a vision, no development skills, and an LLM subscription.
In fifteen days and sixty-eight sessions, I still had no video game. But I had something else.
In short: a game project that turns into an observation lab. Not by strategy — by honest laziness. When the tool becomes more interesting to understand than the product you’re trying to extract from it, the topic flips.
What Rekall taught me
Rekall Studio was not a failure. It was a productive accident. By trying to have an LLM build a game, I found myself observing how the LLM worked. How it drifted. How it forgot. How it produced a perfect result on the third attempt and then a catastrophic result on the fourth, with the same prompt. I was spending more time understanding the tool than building the game.
At some point, I stopped lying to myself. What interested me was not the game. It was the system.
The bifurcation
I transformed Rekall into a laboratory. Not a real lab — no budget, no team, no publications. A telecom engineer alone with a Claude subscription and an obsession with understanding how to make an LLM work reliably.
The beginning was blurry. The lab was too centered on Rekall. The experiments were too specific to a single use case. It took time — around twenty sessions in the lab’s early days — for the subject to detach itself from the project and become autonomous. For me to understand that what interested me was not “how to make a game with an LLM” but “how to orchestrate a system where one of the components is probabilistic.”
The word I did not understand
Architecture. It took me a while to grasp what this word covered. I was using it without truly understanding that it described exactly what I was doing: arranging components with different properties so that they produce a reliable result together. The LLM is a component. The terminal that runs it is a component. The context files are a component. And me — the human who decides, validates, and redirects — I am a component too.
This is perhaps the most important thing I understood: I am part of the architecture. Not as a user pressing a button. As a router. A bandwidth-limited router that decides what passes through, what gets rejected, and what gets reformulated. The system does not work without this router. And the router does not work if it tries to process everything by itself.
In short: the human is not external to the system — the human is one of its components. The other components (LLM, terminal, context files) were designed to interlock with the human’s limits. Remove the router and the network does not crash: it drifts without anyone noticing.
Laziness as a design driver
The best solutions came from my laziness.
Session transfer between two conversations? It was because I refused to repeat the context at every opening. It seemed obvious from the first sessions: if I close a conversation and open another, there needs to be a document that carries the state. It is a concept as old as computing — state serialization. Applied to an LLM, it becomes a Markdown file that says “here is where we stand, here is what remains to be done.”
The triptic — me deciding, Claude.ai formalizing, Claude Code executing — was born from the same laziness. I did not want to type 200-line XML prompts with a high probability of making mistakes and forgetting constraints. So I delegated formalization to Claude.ai and execution to Claude Code. With a few words from me, the system produces a structured 250-line prompt, verified, with gates and validation criteria. My limited router bandwidth became an advantage: the less I type, the more the system compensates.
Pushing the limits to see what breaks
Once the system was in place, I wanted to see how far it would hold. Forty agents launched in parallel on a single decomposed task, just to find out if it would break. It did not break. So I launched fifty-two. The record is eighty-two agents in a single session. It is not useful. It is exploration. Like a child stacking blocks to find the breaking point.
But exploration produces data. And data produces knowledge. I learned that massive parallelism works but that the sequential consolidation that follows is the real bottleneck. That context degrades after twenty exchanges. That orchestration skills format but do not improve intrinsic quality. That the LLM self-evaluates positively and that external verification is needed for every result.
These negative results — the things that do not work, the structural limits that cannot be bypassed — are the most valuable. Nobody publishes them. Academic papers show what works. I document what breaks.
Late formalization
For a long time, I had no thesis. I had observations, decisions, conventions, but no unifying vision. It came around session sixty-nine of the lab — at the end of the second week. Stepping back, I saw that everything I was building resembled an operating system. Not a conventional OS. An OS whose processor is probabilistic.
Memory management, task scheduling, context isolation, dispatch by cognitive type — these are OS problems translated into human language. Because that is what I know how to do. I am not a mathematician. I am not a developer. But I know how to structure my thinking. And it turns out that structuring thought is exactly the problem posed by an LLM in production.
Thirty days
One hundred and sixty-six sessions in thirty days. Sixty-eight to try to make a video game. Ninety-eight to understand the tool I was trying to use it with.
More than five hundred observations formalized with evidence levels. An anti-drift system that detects when conventions degrade. An editorial pipeline that transforms research into public outreach. And still no video game.
The lab is not a product. It has no ambition to become one. It is an exploration space for someone who thinks in tree structures and needs a convergence system for that thinking to produce something tangible. The lab’s harness is my own harness.
And if someone asks me what I do, I answer: originally I just wanted to make a video game.