🎮 Vibe coding part 2: Boombaland, a game built with a team of AI agents

💡 This is part 2. Missed part 1? Start with Vibe coding: building web and mobile apps with AI.

In part 1 I wrote about Oddsprey, my site that predicts football matches with AI. It's live now, and vibe-coded from start to finish. After that I wanted to try something bigger. Something you can't get away with using a few clever prompts: a real game.

That became Boombaland: a colourful 3D game for iPhone and Android where you drop a bomb, run, and watch the board explode. Built in my evenings and weekends, with a team of AI agents writing the code and another AI drawing the art. A few months ago it was a sketch and a document. Now I play it on my phone in the evening, and it launches on the App Store and Google Play at the end of November.

Curious about the game itself? Have a look at boombaland.com. And yes, that site was built with AI too. 😉

What is Boombaland?

In short: the tactical play of Bomberman, but on floating islands above the clouds, on a board that won't sit still. You play 25 levels, from a floating forest to the Castle Road, with puzzles, traps and bosses that really put you to the test.

• Six heroes, each with their own superpower. Blom, Gusto, Frosta, Zappy, Ember and Banshee. Ember even fights by your side.
• Bosses that fight back. Like the Thorn Guard, a living tree that gets enraged while the floor breaks beneath your feet.
• Castle puzzles. Push crates into place and race the hourglass.
• Four difficulty levels. From relaxed to properly tough.

From idea to plan

The biggest trap in vibe coding isn't bad code, it's complexity that grows without a plan. In a game that trap is even bigger. So Boombaland didn't start with code. It started with a conversation with AI about what the game should be, and with concept art.

That conversation produced two documents. The GDD (Game Design Document) describes what the game is: the rules, the heroes, the levels, what makes it fun. The TDD (Technical Design Document) describes how it's built: the architecture and the rules that must never be broken. For example, that the game simulation is fully separate from Unity and always produces the same match from the same input. All balance values live in one file, BALANCE.md, instead of being scattered through the code.

This may be the most important lesson: an AI agent that gets a good plan makes far fewer choices of its own. And every choice that remains can be checked against something written down.

What helps enormously here: good mockups. A sketch of the start screen, the menu or a level shows the AI what you mean, instead of leaving it to guess. One picture of where the buttons go says more than a paragraph of text. I simply paste mockups into the conversation and refer to them from the GDD.

Working with AI agents: memory, agents and skills

I started small: one AI session, one task at a time. In my setup that's mostly Claude Code, but you'll now find the same ideas in other tools, such as OpenAI's Codex. The first thing I learned: an AI agent is only as good as the context you give it. There are three building blocks for that.

Project memory (Claude calls it CLAUDE.md, Codex calls it AGENTS.md) holds the working agreements the agent reads at the start of every session. Every time something went wrong, it became a rule in that file. That way the team learns from its mistakes, even when the session itself has forgotten everything.

Agents are specialists with their own role, instructions and model. Boombaland has eleven: a scrum master, lead architect, simulation engineer, AI engineer, QA engineer and code reviewer on Opus, and presentation, UI, data, performance and build engineers on Sonnet. Each agent works in its own git worktree, a separate copy of the code, so they can build at the same time without getting in each other's way. And nobody checks their own work: QA and the code reviewer rerun the tests themselves. The diagram below shows the basics, with a real example.

Skills are packages of knowledge and scripts that an agent loads when they're relevant. The agent first sees only a short description, and loads the rest when a task calls for it. Among others, I use the official Unity plugin to drive Unity from the terminal, and a skill of my own to run Blender without a screen. Adding a skill is a design choice, though: I deliberately switched off the Unity skills for physics and NavMesh, because they don't fit the deterministic simulation in the TDD.

Which model for which task, and saving tokens

Not every task deserves the heaviest model. I choose the approach and the model from two questions: how big is the task, and how sure am I of what needs to happen?

• Small and clear: one-shot. Changing a text, moving a button, a bug with an obvious cause. Just ask and let it run, usually with Sonnet. For pure lookups, Haiku is enough.
• Medium: plan mode first. A new puzzle or a new screen. In plan mode Claude reads the code and writes a plan first, without changing anything. I read it, adjust, and only then does building start. Sonnet builds, Opus reviews.
• Large and uncertain: plan plus design. A new system or an architecture decision. Update the design document first, split the work into cards of at most about 400 lines, and divide them across agents. This is where I use Opus.

On tokens: a Claude Max subscription is generous, but with eleven agents even that runs out. What saves me the most:

• Hand off instead of resuming. Every session starts fresh from a short handoff file of at most 60 lines: what's running, what's done, what's next. No long old conversations being read in again and again.
• Clear the context at every new task. After a finished card, the context starts clean.
• Only load what you use. Plugins and skills I don't use are switched off. Every loaded tool costs context, even if you never call it.
• No Opus agent to find a file. Where a simple search does the job, you don't need an expensive specialist.
• Tests in batches. Agents don't run Unity themselves. The coordinator collects the work and runs one test batch for all of it.
• Compact terminal output. A tool called RTK trims command output before Claude reads it.

Two AIs: a developer and an illustrator

Claude is strong at code, planning and checking. For images I work with OpenAI's Codex, which can also generate images. They don't talk to each other directly, but through a shared queue: a simple HTML page running locally on localhost:8765.

Claude writes a numbered task (a brief) into that queue. A small script watches the queue and sends me a notification when something new appears. Codex picks up the brief, generates the images and puts them on a review page, side by side and at full size. That's where I choose. My pick goes back to Claude, which processes the image and puts it in the game.

Example: Cobblewatch, from brief to game

Cobblewatch is one of the enemies: a stone guard with a spear. I found the first versions too tame. So Claude wrote brief g138 for Codex, which said, among other things:

• Make R4 from R3, with a clear nose and a large moustache.
• Deliver three options: R4a, R4b and R4c.
• Size 768×1024 with a transparent background.
• Destination in the game: the portrait of enemy 07.

Codex delivered three variants. On the review page I picked R4b, the one with the black moustache.

From there it moved fast. Claude put the portrait in the game and recorded it as decision D-33.412. With a second brief, Codex turned R4b into a turnaround: the same character from the front, side and back. Claude used that turnaround as the reference to update the 3D model in Blender, with the same nose and moustache. The render puts the model next to Codex's drawing, so I can see at a glance whether they match.

The Unity CLI imports the model, the tests run, and everything is committed. And there he is on the board, ready to chase you.

Example: from feedback on your phone to a new version

The best loop starts on my phone. I test the game through TestFlight on my iPhone. When I see something that's off, I take a screenshot and type a note, right in the app.

A real example from 30 October. At 12:39 I'm playing level 25. The game says "This is EMBER! EMBER fights beside you", but Ember is nowhere to be seen. Screenshot, note: "Ember is not shown on the map, during this text."

What happens next is mostly automatic:

• A script pulls the feedback from App Store Connect into an inbox.
• The coordinating agent reads the note and the screenshot, turns it into card D-35.166 and assigns a simulation engineer, in its own worktree.
• That agent first writes a failing test ("Ember is on screen while her lesson shows"), then makes it pass.
• The work goes into the next test batch: over 7,000 editor tests and 2,500 play mode tests, all green.
• A new build goes to TestFlight. My phone updates the game by itself.

The new build was ready that same afternoon. From a note on the couch to a fix on my phone, without writing a single line of code myself. If it's an image rather than code, Claude writes a brief for Codex and the asset loop above kicks in.

What does it cost?

Less than you'd think:

• Time: about one to two months of evenings and weekends.
• A Claude Max subscription for Claude Code.
• Codex for the images, through a ChatGPT subscription.
• Everything else is mostly free and open source: Blender, Unity Personal, Git and the skills. Only the Apple and Google developer accounts cost a small yearly fee.

That says more about the times we live in than about me. A few years ago you would have needed a studio for this.

What I'm learning

• A plan is the contract. With a GDD and TDD, the AI makes fewer choices of its own.
• Small steps, proven by a test. "It works" isn't proof. A test that failed first and passes now is.
• Separate building from checking. An agent can be confidently wrong. Another agent checking again catches that.
• Match the model to the task. Opus for judgement and architecture, Sonnet for well-scoped building, Haiku for lookups.
• The human keeps the judgement. What's fun, which version looks better and what's in scope: I decide. From a moustache to how hard a boss should be.

And in my work?

Boombaland is a hobby project, but it gives me something I use every day: I'm getting better at working with AI tools, and I understand more and more which practices actually work. A good plan, small steps, tests as proof, and keeping building and checking apart. In this setup that's Claude and OpenAI's Codex, but the same techniques are being picked up in other tools too. What you learn here, you take with you.

In my work with Splunk and Cribl, AI and vibe coding are becoming more and more possible as well. Cribl now has its own MCP server, so an AI assistant can work directly with your Cribl environment. You can also customise the entire Cribl interface or build your own features into it. With Splunk, you can recently also use the frameworks Splunk itself is built with to create your own apps and visualisations. With an AI agent that gets the right context, that's no longer a project of months, but of days.

Want to play?

Boombaland launches on the App Store and Google Play at the end of November. Can't wait? There's a private beta for iPhone and Android. Send me a message with "Boombaland beta" and tell me whether you have an iPhone or Android, and I'll send you an invite. Feedback is more than welcome, and who knows, you might see your note in the next build.

Everything about the game, the heroes and the levels is on boombaland.com.

Get in touch

📬 Want to join the beta, talk about AI agents, or hear how I apply this with Splunk and Cribl? Get in touch via the options below, or send me a message on LinkedIn.