My large person project is the Wide Game Bot. This is a pretty complex system involving WhatsApp, OpenAI and Kubernetes, Postgres, REDIS and Cloudflare currently sitting on a DELL 7070 Micro in my home office. It has already successfuly branched out into a different kind of wide-game, the Scouts Christmas Party Planning Wide Game, and work on our location based urban wide game continues.
The system has two components which I wish to open source. This is as much as a demonstration of my abilities without revealing my main intellectual property, the game system. There is also the hope with all open source that these things become useful in their own right, and maybe they can grow more as open source than I will achieve on my own.
Go AI Tools
Go Ai Tools is at https://github.com/m0rjc/goaitools. This provides connection to OpenAI, a tool calling Agent loop and support for message state tracking.
Go WhatsApp
Go WhatsApp is not currently released, although it exists as an independent module in my codebase. I use a redirect in the go.mod file to allow local development. It currently does not support egress rate limiting and does not understand message receipts. These are critical requirements for a production system, and without them I don’t believe I can release this code to the public.
Switching Hats – The difference between two worlds
My work on the bot is quite experimental really. I’ve built it up, torn it down, thrown Claude Code at it. I’m working with a system with flaws that I’ll get to fixing as I go. It’s very much an early days research style project which is allowing me to rapidly iterate, test and come back and reiterate.
My work on goaitools is like wearing a different hat. Even though it’s still a pre-release version (currently v0.3.0) I’m working to Stories. I’m ensuring that tests are in place at every step, something that’s already served to reign in Claude when it gets things wrong. I’ve tried to make the tests behavioural and wonder if I can tell Claude in its CLAUDE.md that it should always be this way. There is documentation. There are samples, which are also system tests. There is a backlog and release plan.
AI tools make large changes relatively cheap, but I am trying to build goaitools properly, with isolated components and separation of concerns divided through small interfaces. This is more how I have worked in my day job. It reall feels different to the wide game bot.
Which is better?
It’s a good question. Wide-Game-Bot can evolve rapidly. It accepts a mess. One day I’ll make those hard component boundaries (before it becomes too messy) but I’m heading there incrementally. GoAiTools feels slower because I’m being more thorough. When I wear my goaitools hat I’m no longer the bot developer. My interest is in that library and my other self is very much on the other side of its boundaries. I don’t compromise GoAiTools for the bot project.
Claude and large intertwined codebases
I may have to compartmentalise the wide game bot sooner rather than later, as Claude struggles to cross compartments. This is resulting in a lot of “stabbing in the dark” as it tries to make changes.
I think things like this would be reduced if the codebase was made of smaller components with well defined boundaries. The components exist in my head, but rapid work with Claude has been less disciplined. An issue is managing dependencies.
I’ve seen the same with human teams working under pressure and it comes back to the same question about developer discipline and maintaining structure in a project. Why does processor.go know about conversation TTL anyway? Its job is to route requests to the right agent, not to be the agent itself. Claude, like a human team, degrades if the system is allowed to become messy.
Unit Tests
I’ve seen Claude correct itself quickly due to failing unit tests in GoAiTools. At least component tests, verifying the contracts between system parts, allow errors to be spotted sooner.
So which is better?
So to answer the question of which is better – the stricter work on GoAiTools may feel slower, but I think in the end it wins out for the same reason that maintaining developer discipline and looking after tests wins out in traditional projects.
Leave a Reply