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.
An example of Claude stabbing in the dark on the AI Bot project.
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.
I’ve been working with multiple AI tools both professionally and in my own time for a while now. At home I have a personal Claude Pro account and use Gemini on the web as well as my own OpenAI developer account. I have used OpenAI to help with tasks (“You are an expert in planning activities for Scout Groups....“) and programatically in projects like the WhatsApp Party-Bot. Gemini does research for me and can help with code snippets and understanding, somtimes giving a second opinion to Claude. Claude is my main code assistant.
It’s certainly helped with rapid prototyping and iteration on a project. I was able to work on the Party-Bot, adding features and fixing things on a live system as I received user feedback. Party-Bot now has a traditional web page too, for those who don’t like the conversational UI. This was all built in hours.
Some of my working patterns
My employer uses SpecKit. This reminds me of the old days before Agile when we designed and specified projects! We turned a project around this way. My first project with Polk was a restart on a failing project. We spent weeks planning it. I developed my reputation as “A Danger With Whiteboards” due to the amount of UML that I drew on them. Management worried about time spent without any code being written, but when we wrote the code we delivered a fully functioning system in less time than the failed project had wasted. The system was also robust to change as customer requirements came in.
Agile has always been “mini waterfalls”. I like to point to pictures of Aysgarth Falls in the Yorkshire Dales. In my time leading the Foundations Team in FinancialForce (now Certinia) I’d spend the first half day or day of a sprint with those whiteboards. We’d work on specifying exactly what we were going to implement.
A beauty of this is that any questions that arose could be dealt with before we all went away and worked. Everybody knew what they were doing. I’d insist on what I consider to be “mathematically correct systems” in which we knew what the definition of the system was. Some Agile purists disagreed, wanting strict focus on the User Story at hand. We could design the system with clear contracts allowing differerent developers to split work and come together later – and it all worked in the end!
My WhatsApp Game Bot framework has reached the stage where different teams could go off and implement different subsystems all independently now – but there’s only one of me on this! I’ve been here before. “You need a team. You don’t scale on your own”. The bot can only be split because I have driven Claude to write a modular architecture. If you let it make spaghetti then you cannot factor out parts this way.
Mini-Waterfalls with Claude
Claude tends to create a SpecKit like Story structure, even without SpecKit installed. I’d have it work with me on the research and specification, using Planning Mode to help me work out and write the story. I’d then write the story file and write a planning and task list.
Writing out tasks lists allows me to start afresh in a new Claude Context. Context costs, because we’re paying for tokens. It also can slow things down, and I’ve found that if you give Claude too much information it’s more likely to go wrong. Claude has to be told to tick off tasks as it does them, or it forgets. Keeping the task list up to date allows for better recovery should the session be lost for any reason.
I switch between policing every change that Claude offers and letting it rip with a review at the end. A lot depends on how confident I am with the specification. Policing every change allows me to trigger a change in direction if I see something I disagree with. This saves a big refactor later. Letting it rip could mean not having the work quite as a I’d do it, but having something working then deciding whether to refactor or not. I’ve not had Claude go wildly wrong. It’s easier to delete a broken AI generated branch in Git than it is to tell a team member a day before the end of a Sprint to rework everything!
Habits to Change
This is how I work with humans. I ask a question even though I know the answer. With humans I may keep asking to get to the point. I want the person I’m helping to work it out so that they understand.
Asking Claude questions, not just giving it commands
This wastes tokens when I’m working with an LLM. I know what I want. I should just demand it. In this case Claude came to the same conclusion that I’d already reached. This was to correct a decision that Claude had made earlier as part of a large refactor, in which it was marshalling enums across the layers. You can’t have switch statements on Game Type buried in multiple parts of the code when all that matters is that Game Type is read from the database and used to find the correct Game Strategy based on name.
Like hitting a golf ball down a course, if you’re not Tiger Woods
The AI isn’t perfect. It doesn’t do things the way I would. But then am I perfect? Definitely not! Development of any system is iterative. I like to think of it like hitting a golf ball down the range. I’m not particularly good at aiming golf balls so I’ll hit off to the side a few degrees or tens of degrees, but the aim is roughly right and I’m moving forward at every stage. I then need to go find the ball and hit it again trying to correct.
The Dynamics of Refactoring
One of the fundamental promises with Agile Development is that we can refactor. The idea is that we must spend time collecting the technical debt that we accrue. Ideally we should allocate time to keeping on top of this and maintaining the system. This is hard to do in a business environment that is always under pressure to deliver. The business wants features. Refactoring is not feature delivery.
Not refactoring is false economy. The system degrades such that working on it becomes slower and more expensive. A good system with good separation of concerns, sensible dependencies, SOLID design is easier to work on. I’m trying to keep the Game-Bot this way because time spent making that foundation allows for faster iteration down the line. If the foundation is good then all I need to do is write the new feature business logic or the new Web presentation layer. I think Party-Bot is going to become primarily a web interface built on top of the same Domain and Business layer as its WhatsApp incarnation.
As Foundations Team leader I kept “Richard’s Red Refactor List” of things I wanted done to maintain the system. We allocated time, sometimes a whole sprint, to clear that list. This kept a system that was easier to work on. Nowadays we have a Technical Backlog in JIRA and pull technical stories into the sprint as needed.
Claude makes refactoring cheaper than it was. Will that still be the case when Claude has made delivering features cheap? I think this will level out. In a team situation we’ll still be potentially disrupting work for a large refactor, so the task of coordinating in a team remains. Claude does remove a lot of the grunt-work – the rippling of change through the codebase if you change a low level interface that everything depends on. (Back in my Java days I found Eclipse’s refactor tools were great for this. I’ve not seen anything comparable in any other IDE since.)
Currently, for this sole developer, refactoring is cheap – or relatively cheap. There’s still an Opporunity Cost…
The Claude Rate Limit Dialog – Stop and wait or pay for more?
The plight of the Junior Developer?
£18 per month for Claude Pro is significantly cheaper than a junior developer! This cannot be denied and its impact on the industry is going to be profound.
Claude still needs guidance. My job remains safe – for now. Perhaps it always will, or will for long enough for me to reach retirement, because a fundamental need in software engineering is to nail down requirements. User wants are often fuzzy. Computers, even Claude, need definite rules to determine what the system must do. They need that “system definition”.
So what happens when all the seniors retire? Who will take our place? Who will have learned the ropes and gained the experience? Who will be able to tell Claude it’s made a massive security hole or be able to drive it towards laying out that scalable system with its well designed components?
Maybe AI is just the next Industrial Revolution or Communications Revolution. I lived through the 90s and saw the last one. We take the web for granted now – it’s such an invisible part that underpins so much that a UK political leader once pondered whether the state should be as responsible for ensuring access as it currently is for roads.
Maybe the next junior developer will be someone entering the workplace ready to use the new tools, as a past engineer may have entered the workplace ready to use a CNC machine tool (or MATLAB for the kind of stuff I studied). AI is an automation. Improvements in tooling for the physical world have increased scale. Consider the robotic warehouses we see now. But automation also impacts jobs.
I think the biggest question is whether demand will keep up with increase in supply, as software engineers become capable of doing more in less time.
