Creating apps while walking the dog
I am embarrassed to admit that I enjoy using voice to text on mobile with AI, and was discussing project ideas while out on a walk. I wanted to see how far I could get releasing a game mod without writing any code. A full, finished product from planning to launch, that people could install and play.
A few evenings later, after many mistakes and lots of trial and error, I uploaded my first real mod on the Steam Workshop.
I chose Project Zomboid, which, now that I write this, I am a bit stumped on how to describe to someone who doesn't play video games. And also how I should describe a "mod" if you haven't come across one before?
For now, all you need to know is, my mod (PZA) adds 28 achievements / in game challenges for advanced players to experience.
For a quick description of how it looks in game: every new player character now starts with an empty photo album. If you complete a challenge, a Polaroid appears, stamped with some information like "date unlocked" to add some in game flavour. There's a gallery in the main menu to track all the challenges, and the polaroids can be shared as physical objects in online games.
Simple enough on the surface, but as none of this exists in the "base game", it meant building new menus, inventory items, custom code that listens for in game events, event tracking, saved data and client + server behaviour for online play, THEN getting the whole thing published for other players to find.
AI wrote all of the code and documentation, built the graphics, and helped work out the release process.
My role was to decide what we're actually making, organise the project, test it, find bugs, and provide direction to keep the project moving.
I highly recommend if you are someone who wants to make something with AI coding, to start with a game mod. The big assets like game engine, 3D models, UI and audio already exist, so you can concentrate on executing a single idea.
How I actually built it
At least for now, we still can't really tell an AI, "build me a video game mod" and come back to an interesting, complete project.
The initial conversation was for exploring how we could make something functional and small enough to finish. The AI then turns your ramblings into a coherent design document. I handed the doc to a new chat on the computer with something along the lines of:
"Hello robot friend, you are now the Lead Engineer on my project, nice to meet you pal."
In the end, I used around ten agents across the build. I always found "Agents" to be a misleading term, because it really means "separate chat threads with distinct jobs". It is up to us as humans to conduct the agents by passing information and instruction between them.
| Job | What I asked it to do |
|---|---|
| Project manager | Keep the plan and project notes up to date. |
| Lead engineer | Design the framework, brief engineers and review their work. |
| Content engineers | Build individual features from a shared brief. |
| Outside reviewer | Check the code without trusting the project notes. |
| QA lead | Build automated tests, and give me a list of things to test in game. |
| UI and art | Make the menus, icons, thumbnails and other graphics. |
| Release engineer | Work out publishing and live updates. |
Above you can see the chat threads (and their token cost), which usually followed the same loop:
- Talk through one feature with the PM or Engineer bot. What is the end result we're aiming for?
- Get a brief from the lead engineer. Paste that into a new chat thread, rather than having everything in one massive conversation.
- Ask for a report when the new feature is ready. The lead checks the code alongside the engineer's report.
- Try it in the game. I play through the new feature, and describe anything wrong and what needs changing.
- Iterate until happy. Update the project docs, then move on to a new feature.
My input was purely conversational, usually dictated through the microphone, and I have stopped wasting time trying to craft perfect prompts. These days I ask the AI to turn my nonsense into clear instructions for the next agent.
I used DeepSeek for 90% of the build and Claude for one or two trickier debugging sessions. This was my first time using DeepSeek, and I was shocked at the amount of great code written for very little money. Bringing in Claude for specific problems kept the total AI usage around $20.
The lesson here is keeping each piece of work small enough to check, and knowing when an agent is clearly stuck on something that would benefit from a fresh perspective or more powerful model.
Sometimes things seem OK but are secretly broken
Project Zomboid had just had a big update to Build 42, so most of the modding advice online was out of date. An early feature I tried to build looked reasonable and passed tests, but it was calling a method that didn't exist anymore.
The code tried to register items through the game's script manager, whereas those items actually had to be defined in text files. "Defensive" error handling written by the AI meant the failures were nearly impossible to detect. In other words the code wasn't working, but the AI had set it up so reports were saying everything was working fine.
The save system had a similar problem: newly invented file functions and nothing written to disk.
What this meant in reality was the project was completely stuck and going nowhere, despite the agents' best efforts to debug it. After many wasted hours the solution was to ask a new agent to read the game's installed source files instead of referring to documentation online or guessing. Thousands of readable Lua files were already sitting on my machine, and it didn't really occur to me that an agent can just read the raw game files for answers to our assumptions.
This is now a repeatable and incredibly effective use of AI: searching through unfamiliar code and finding working examples. Our OnPlayerCreate event was actually OnCreatePlayer. The zombie death handler expected two arguments, but the game passed one.
We recorded the verified methods for future agents in our project docs, and made sure failed calls log something useful. Which, in hindsight, may seem super obvious now, but was a revelation to me being new to coding.
And the thing that blows my mind still is we simply need to tell AI agents to do this without understanding what it really means, and they'll happily oblige.
A second opinion changed the build
By the end of the first week, a basic version of the mod seemed to be working. So I spun up a fresh Claude chat to review the code, specifically instructed to not rely on any project documentation.
It found two systems that were supposed to be working together but had never been connected: progress tracking and achievement definitions.
Apparently achievements were being triggered by individual lines of code naming each distinct feature (which is very bad, said Claude). Every new achievement meant more special case code.
Mr Claude helped connect the systems properly, so that achievements could describe what they wanted to track as data: "Watch places visited, look for this specific location, and use this character's progress."
That gave us a shared framework for 28 achievements, driven by seven signals (instead of 28 achievements managed by 28 separate signals). For example, the 16 achievement "Pilgrimage" challenge to visit a bunch of key locations in game, used one signal and three types of condition. Adding another location became a data change rather than a bunch of new processes.
Claudius also noticed that our project notes and documents had drifted a fair bit, as I had been doing a lazy job of coordinating all the important changes between all the agents. Strange things can drift in docs, eg something I had planned to do had been confirmed as implemented at some point in time, but was a lie that every agent was reading as truth, which can lead to all kinds of errors if unchecked.
With Claude we separated what we still needed to do vs what was confirmed in the code: a roadmap for plans, a dated log for completed work, alongside our reusable engineer brief and in game QA checklist. These refreshed notes made it so new agents can accurately join the project without needing to rediscover everything each time, and making sure they don't have a bad start reading from false documents.
The important lesson to share here, is that one of the greatest strengths of AI is documenting everything. What is the plan, what are the important lessons, what has been done, what have we still yet to do? Use agents to keep these docs up to date and you will save a ton of time, tokens, and headaches.
Testings and Debuggings
Inspired by an excellent Factorio development post, I now always ask my AI friends to build an automated test suite as we develop each new feature. Crucially, you don't need to understand what automated tests are, how they function, or what's being tested.. but if you ask for it, the AI friend will agree that is a great idea and get to work.
By the end of phase 1, it had 485 checks across 56 test cases, running and completing in only a SINGLE SECOND.
What does this mean? Well in this instance it means we had a bunch of scripts that load the mod files, with small stand ins for the game functions (eg signals, triggers). This means that every engineer could run the scripts after something is changed, and see if we get a pass or fail.
If everything passes, we know we didn't just break something important, and we can move on, after asking for a NEW set of tests to make sure the latest feature we just built doesn't get broken by the next agent. It is a beautiful efficient loop that I recommend to everyone coding with AI (this website even has a set of tests that gets run every time we edit or build a new page!)
Incredibly useful, but not a perfect substitute for testing the thing with your own eyes.
At one point, 364 checks were passing while two bugs sat in the code that called the tested helpers. We'd checked the functions but missed the places they were used, which was impossible for the AI to see.
Later, I made a new character and completed one challenge. Several achievements unlocked, including places this test character had never visited (aka something had broken really badly).
Being a daft lad, I couldn't explain the code or share any technical hypothesis for why it might be broken, but I could give the agent useful clues: in this case not ALL achievements were misfiring.. this specific bug had something to do with locations persisting across new characters.
That was enough to help it find the problem, which it could never see in the code alone without being directed. It turned out that some achievements were reading progress stored across the player's whole account, when they should have only been checking the new character.
The blue text in the picture above is my plain English, voice to text instruction for what is broken or what I want changed.
And the lesson here cannot be stressed enough: Fixes are quick once a change or a bug is identified, but generating useful feedback means playing the mod or testing the app, paying attention, and describing the difference between what is expected and what is happening.
It is easy to become lazy and stop proper testing after the 30th iteration, but make tests convenient for yourself (eg God mode or Dev mode), use voice to text so you can make notes while hands on, and make human QA a recurring part of the project.
Effort vs Reality
This is one of the things I find most exciting about the project: how much work I was able to get through in such a relatively short space of time.
Here are some broad estimates for a competent developer attempting the same project without Project Zomboid modding experience. They're estimates, not measured averages, so please tell me if I am wrong here!
| Work | Estimated hours without AI |
|---|---|
| Learn Build 42 modding from scattered and outdated guides. | 20 to 40 |
| Read the game's source to find the right functions, events and arguments. | 15 to 30 |
| Design the achievement framework and character + profile progress tracking. | 20 to 30 |
| Write roughly 5,700 lines of commented, working code. | 100 to 150 |
| Implement multiplayer functionality, client/server boundaries and syncing. | 20 to 40 |
| Build the 485 check test suite and its stand in game environment. | 20 to 40 |
| Diagnose a Linux file path bug with no useful error message. | 5 to 15 |
| Write the project documentation, reusable briefs and user guides. | 20 to 30 |
| Set up publishing and live updates. | 5 to 10 |
| Total | 225 to 385 hours |
That's roughly six to ten full time working weeks.
My AI assisted build took ten evenings over two weeks, with most of the work happening in four fairly heavy sessions. AI usage cost about $20. In total, that came to 74 commits and roughly 13,800 lines added.
Those evenings included planning, coordinating agents, testing, giving feedback, and pushing the project forward after each new feature.
It's worth noting that probably an entire evening or two was spent working on errors produced by AI, eg fixing its own mistakes or getting stuck in loops it couldn't break out of. An experienced mod developer might have avoided those entirely.
Even with that, I saw a project to the end that I couldn't have coded myself, in the spare time I had available after putting the kid to bed. It is a dream come true for me to produce something useable by other people, that I couldn't develop before the existence of our AI pals.
What came out of it
PZA is live on the Steam Workshop. It shipped with 28 achievements, works in single player and multiplayer, and has been tested on Windows, Linux, Steam Deck and Mac.
People downloaded it and favourited it on day one, which was a shock. Something that started with me speaking nonsense on a dog walk was installed and used on somebody else's computer. That was a nice moment.
There's a version two roadmap now, and I'd like to keep improving it with feedback from people who actually play.
I didn't write the code, and it's tempting to understate the role humans play when AI is coding everything. But coming up with an idea, breaking the work down into useful pieces, giving good feedback, keeping track of everything, and seeing something through to the end takes real effort.
At least for the time being, humans play a critical role in development alongside AI (I wonder how I will feel reading this back in 5 years time).
If you've got an idea you've been putting off, start with a small version you can actually test. Talk it through at a top level first, build one piece, try it, and work out what comes next.
And if you're building something, stuck on something, or have a better way of doing any of this, I'd love to hear it.
Email me any time ~