An AI Software Launch

What am I trying to prove?

I am curious, and constantly trying to find an answer to the question: What is achievable using only AI code? What is the limit?

I am sure many more ambitious things have been achieved with AI, so I should also highlight my personal constraints of low budget and low IQ. I started this project as an attempt to try and produce something real, something complex but something I can understand, and something that has value to a real audience.

This case study is an attempt to take what I made and share it with anyone interested in making something yourself. Each section below shares a lesson you can use. None of these lessons are exclusive to game development, and can be applied to ANY idea you have.

I will share you how one person can complete a real software project end to end using AI for all of the real work.

I picked a game called Project Zomboid and set out to build a mod called PZA, which adds an achievement system (a set of challenges) to a game that has never had one.

My role in the project is limited to the ideas-man; I tested, I gave feedback, and I coordinated. I did not write a single line of code.

Why a game mod?

It is good to take on a project with natural constraints. It is also incredibly helpful to start with existing foundations, art and UI. I have enjoyed building small games and apps from scratch with AI, but it is difficult to create 3D assets and takes time to build complex systems. By choosing the modding space, we inherit all that for free.

Some fun challenges and "learning opportunities" came out of building on top of an existing thing:

The documentation is thin and partly wrong. Project Zomboid modding relies on community knowledge, a wiki that lags behind the game, and reading other people's code. The game had also just moved to the big new Build 42. Most of the guides we find online are now outdated.

The API is not guessable. You cannot always reason your way to the right answer. You have to go in and look.

It has a real audience. Project Zomboid has a large, passionate and opinionated modding community and player base.

The concept of the mod is simple: We create a bunch of fun challenges for the player, a gallery in the main menu tracks which challenges a player has completed. Every new character enters the world holding an empty photo album, and when you unlock an achievement a Polaroid gets added, stamped with who earned it and the difficulty they were playing on. This polaroid system adds theming and world building flavour, while also making achievements shareable in Multiplayer.

The AI team

I used around ten dedicated AI agents across the project, each with a "real world" role.

For larger ideas I have found that if you use a single general assistant for everything; you quickly hit memory limits, spend a ton of money on tokens, and weirdness starts to creep in as the context window grows.

Splitting roles between different threads simulates the specialisation that a real team has, and helps you compartmentalise tasks. For example the lead developers job is to review the different engineer agents code. The PM's job is to help direct the team, and keep documentation up to date.

The roles I used:

By breaking out tasks into these different threads and giving each agent a clear role and set of instructions, you can get more accurate results and save a ton of money on tokens.

Managing cost + agents

It is a good idea to split the work between models based on difficulty / complexity.

Cheaper Deepseek agents handled the high-volume work. Things like the initial framework, project coordination, UI, documentation, and repeatable + new feature implementation.

Claude handled key challenges that needed weightier thinking, such as code review, and debugging specific problems.

Deepseek was the biggest surprise of this project. It is miles cheaper than Claude, and was fantastic for getting 90% of the project up and running. Claude's more powerful model proved instrumental in getting the final 10% working.

The actual input from myself was almost purely conversational. I never spent time manually typing out complex, highly engineered prompts. Instead, I'd use voice to text and natural language with the Project Manager or Lead Engineer bot, and have them create the prompts I could copy and paste over to new agents.

In fact, the very first conversation before starting the project began with a "game design" agent, spitballing ideas while on a dog walk until we got an idea that was fun, but not overly ambitious. The AI then turned the nonsense I was saying into a decent project design document. From there, I simply open a new thread in Visual Studio, Claude Code, or wherever, and say "Hello robot friend, you are now the Lead Engineer on my project, nice to meet you pal", then share that project design doc. The lead engineer then maps out the initial architecture, and builds the idea into a roadmap with sequenced tasks.

You don't need to write complex or finely tuned prompts. Instead I use voice to text, informal conversations with our Lead Engineer, where we can ask to create prompts designed for the next agent, and the next area of development.

The loop

The lead engineer takes my incoherent ramblings and turns it into a useable prompt.

A NEW chat window for a Content Engineer builds the feature from the prompt, then shares a report when finished.

The Lead Engineer reviews the report alongside the new code, then prepares the next prompt.

As the project progresses and fresh context windows are needed, new threads are created for a QA lead, a UI/UX dev, a release engineer.. and so on.

My job through the entire build is simply to direct traffic, test everything, play the game, make sure the ideas are fun, and keep all the agents in check. The key is to spot where the things feel wrong, working on new things incrementally, and letting the agents translate my thoughts into actual engineering work.

Early errors: How AI confidently builds something that could never work

This points are slightly more technical, so feel free to skip ahead to the conclusions!

The first version of the code tried to register our new in-game items types at runtime, through the game's script manager. It passed early tests, looked completely reasonable and was structured well, with error handling in case anything goes wrong. Amazing!

It also never worked outside of the early tests, because the method it was calling does not exist. Project Zomboid has no way to register items from code at all. Items can only be defined in text files.

To make it worse, the code was written "defensively". Every call was wrapped in error handling with a fallback value, so when the call failed, nothing useful was logged. The system reported success while doing absolutely nothing.

The same pattern turned up again later, where the original save system was calling three more file functions that don't exist in the game. Same defensive wrapping and failures, with a cheerful printed message about a missing JSON library while writing nothing to disk.

Long story short: this is exactly the type of failure we should worry about with AI-generated code. We embrace things that are obviously broken, but it's a nightmare when something is written that looks right, fails in silence, and tells you it is working the whole time.

Two big lessons came out of this:

Stop guessing, start reading. We told an agent to go and read the game's actual shipped code, which was installed physically to our machine, to find out what methods really exist.

We added a rule in our docs and a helper for it. A small utility that runs risky calls but logs when they fail. Every future agent reads these rules and comments in the code before they can write silent fallbacks.

Reading files to find the truth

This was a revelation that changed everything: Making an agent read the game's entire installed codebase.

Project Zomboid ships its own game logic as thousands of readable Lua files. For AI, this is even better than documentation, because it's what the game actually does rather than what someone wrote about two versions ago. While exhausting for a human to pick through, the AI is able to scan it and take away key lessons quickly and cheaply.

Once our agents were working from the source, a whole category of problems disappeared. Some examples of things we found that no guide would have told us:

An event with the wrong name. The code was listening for an event called OnPlayerCreate. The real one is OnCreatePlayer, which is just similar enough to make it infuriating for humans to spot.

An event with the wrong number of arguments. The zombie-death event passes one thing, the zombie. Our handler was written expecting two, so the second was always empty and the function bailed out on its first line. The "kill your first zombie" achievement could never have fired. We found the right answer by reading how PZ's very own in game tutorial section uses it.

A missing language feature. Project Zomboid uses a cut-down Lua interpreter that doesn't include next(). I don't fully understand why this is bad, but the Lead Engineer was very happy to discover this, and soon reworked many lines of code.

Every one of these was found by reading the game files, and these discoveries were written down in our own project's own documentation. Meaning once the research is done and the lesson is learned, it is saved for all future agents to reference.

Hidden architecture ghosts

By the end of the first week, the mod seemed to be working perfectly.

This is the point where I like to give a new, more powerful model (like Claude) access to our project files, with instructions to act as our "outside consultant" and perform a full code review.

The agent is more expensive, but used sparingly in this way was able to find something super broken for a reasonable cost.

There were two systems in the codebase that were supposed to work together and had never been connected to each other at all. One tracked progress (places visited, nights spent somewhere, hours survived..) the other held the achievement definitions.

The plan had always been that one feeds the other, but nothing in the code actually referenced the progress system. Every single achievement was being woken up by a hand-written line of code naming it specifically. Every new achievement would have meant new code, in a new place, with a new chance to get it wrong. The design document described a system that the code did not implement, and everyone had been happily building on top of it.

The fix was to build the connection properly. Achievements now describe themselves as data. An achievement says "I read the places visited signal, I care about the entry called Rosewood, and I count the per-character version".

The result was 28 achievements run off 7 signals with zero per-achievement logic. Adding more locations is now just a small data tweak. The entire Pilgrimage challenge (16 achievements) is one signal and three shapes of question.

This "outside consultant" method is invaluable, is a great way to make sure we are using the more expensive models sparingly. That architectural gap went unnoticed for a week because the documentation specifically said it was handled. Which leads to the next lesson..

Documentation traps, and the fix

At one point three separate documents referred to a version checkpoint that had been created for the project's core code.

However the checkpoint had never actually been created. The statement had first been written down as an idea in a plan, then referenced later as a fact, then referenced again as established history. Three documents all agreeing with each other and all of them getting it wrong.

This is a critical and common failure with AI-generated documentation. Docs are designed to be gospel truth, and new agents read the docs when first coming online. If a document contains a confident falsehood, the next agent inherits it and repeats it, and it hardens into something everyone believes to be true.

Luckily these can be caught by bringing in new agents as outside consultants and instructing them to ignore the docs, told only examine the code base.

The best way to prevent this early in a project is splitting the documentation by what it is allowed to claim, for example:

• A living log that only ever records what actually happened, with dates. If it says something was confirmed, a human (me) confirmed it in testing.
• A roadmap that owns every forward-looking statement.

By the end, the project had around 26,500 words of documentation across eleven files, here some highlights you can use in your projects:

The roadmap holds the plan, including a section of known technical debt where each item is written up with what it is, why it was deliberately left, and instructions for whoever picks it up. "Bad things" that agents new agents continuously pick up on are noted in there as accepted to avoid annoying repetition.

A content engineer brief which is the reusable instruction set for building one new feature. Fill in four blanks, hand it to an agent, get a new feature built to the agreed standard. This is what makes content injection repeatable, and where important lessons and pit falls are saved.

An in-game QA testing checklist written specifically for someone who does not read code (me).

A publishing guide with the full release process from editing a file to a confirmed live update.

The thing I can't recommend enough: documentation is not boring overhead. It is collective memory. The docs are the save files that will spare you a ton of wasted time, tokens and errors. Never start a project without a design document, and make sure documentation grows with the project. Just ask the AI to create it and update it for you whenever something big happens.

The value of testing

Inspired by a fantastic blog post from the Factorio team (https://www.factorio.com/blog/post/fff-438), I always ask an agent to build an automated test suite. By the end of V1 it was 485 individual checks across 56 test cases, and it runs in about a second with no game needed.

It loads the real mod files, not copies or reimplementations, and runs them against a small stand-in for the handful of game functions they touch. So when a test passes, it's the actual shipping code that passed.

Two details I'd call out as better practice than most projects manage:

The tests were proven to work. It's easy to write tests that pass because of how they're written rather than because the code is right. So each fix was deliberately undone, one at a time, to confirm the tests failed on exactly the right checks and nothing else. Then put back. A test suite you haven't tried to break is a guess.

The suite found its own blind spot. The tests covered every helper function and none of the places those functions are actually called from. It was green at 364 checks while two real bugs sat in the gap. Both were in the same seam. That's now written up in the testing notes as a lesson, because the general version is useful: a test suite that stops at the last pure function is testing the part that was already easy to get right.

This is critical, because every agent working on the project can run the tests after making any changes to the code and confirm that nothing is broken. You should instruct each agent that implements a new feature to create a new set of tests to add to the suite.

Bugs AI can't catch, but humans can

Everything was green. Tests passing, code review done, fixes in. I loaded up the game to do a final pass, made a new character, tried to complete an achievement.. and something was broken.

I'd only completed one challenge, but multiple challenges were recorded as complete. The mod was awarding a brand-new character achievements for places they had never been to.

I didn't know what caused it. But I was able to observe that two of the basic test achievements were not misfiring. After sharing this observation with the Lead Engineer agent, it was discovered that the script was reading the mod's own progress records, which are stored per profile so that certain achievements can work across multiple characters and play throughs.

The fix only took a minute once discovered, but could only come from playing the game and paying attention to which things were behaving correctly, which is not something the test suite or AI could uncover.

The lesson: AI is very good at building the thing but not very good at knowing what it feels like to use it. Every AI project needs a person to sit there and experience the end result, and the more frequently you do this, the easier it is to spot and fix broken things.

How long would everything have taken without AI?

Estimates like these tend to flatter whoever makes them, so here's a breakdown, and please feel free to disagree with any of it, as I am not a rapper.

This is what a competent developer with no Project Zomboid modding experience would have had to get through:

Lets call it six to ten weeks of full-time work. Or for someone doing it on evenings and weekends, which is how most personal projects go, that's four to eight months. And that assumes they don't give up at the point where things stop working for no visible reason, and you're smashing your head against the wall trying to resolve obscure multiplayer bugs.

What it took me with AI: ten evenings, spread across two weeks of calendar time, with the bulk of it landing in about four heavy sessions. 74 commits, roughly 13,800 lines added in total.

My own time in that was mostly spent coming up with fun ideas, iterative testing, dictating what I saw, and confirming what agents should do next.

There are two honest caveats:

Some of those hours didn't vanish, they just moved. The time I spent coordinating, testing and giving feedback is real (sometimes boring) work. It's just work I'm better at than writing code.

Some of the AI's time was spent fixing the AI. The item registration dead end, the save system that was writing nothing, the architecture gap that sat there for a week, the "multiple achievements at once" bug. A human expert probably wouldn't have made those mistakes. The speed advantage is large, but it is not without downsides and wasted time.

What actually made the project work

If I had to compress the whole thing into the parts that mattered:

Never start without a design doc. Spend the time shooting the breeze with an agent, give it your ideas, ask where we're being too ambitious, get a concise plan together early on.

Separate the roles properly. A reviewer with no stake in the code found two launch blockers after one pass. An engineer reviewing its own work would not have.

Build incrementally, iteration is key. Don't throw in a bunch of new features or ideas at once, break things down into bite size chunks, develop one piece at a time, test and feedback as you go.

Treat documentation as memory. Written decisions are the best continuity you get. Have agents write down why decisions were made, not just basic updates.

Make the AI show its sources. Insist on thorough code commentary. "This function exists, verified in this file at this line" is worth a hundred times more than "This should work".

Test the tests. Break each fix on purpose and check the right test fails.

Match the model to the task. Cheap models for volume, expensive models for analysis.

Be the user. The most valuable thing I did all project was play the game and notice something felt wrong.

Where we're at now

The mod is live on the Steam Workshop. It shipped with 28 achievements, works in single-player and multiplayer, and has been tested on Linux, Windows, Steam Deck and Mac.

It picked up downloads and was "favourited" on day one, which was a pleasant surprise. The end result is a real thing, that real people installed and used, rather than a screenshot of something that only works on my machine.

Despite this originally being a project just to see what is possible with AI, I am now invested and committed to producing something the community can enjoy. There's a roadmap for version 2, and I would love to get to a 1,000+ subscribers, with real feedback from real users.

Conclusion

I didn't write the code. I just had an idea, set up some chats with AI, tested as we went, then said what was wrong or what could be better.

I like to down play the significance of the "human input" to encourage anyone to get stuck in, but this is a real skill. Knowing how to split a project into roles, what to write down and where, when to stop the AI once it is stuck in a loop and get a second opinion, which model to point at which problem, how to describe a bug clearly enough that someone else can find it..

Most of the value comes from doing it efficiently, both in time and money cost. The rest of the value comes from the quality of the idea, your ability to see it through to the end.

The thing I'd most want someone to take from this: the gap between "I used AI to write some code" and "I ran a project with AI" can be large. Almost all of it comes down to a good idea, good planning, and good structure. But the models are already good enough for you to start an idea you don't know how to code. What's left is how you organise them.

If you've been wondering whether this is actually possible, it is. And I'd love to talk to you about your own idea, or any questions and feedback you have!

Email me any time ~

[email protected]