Module 4 · Case Study

Case Study: A Billion Bees 🐝

The previous page explained what vibe coding is. This page lets you watch it happen. Josh, a gamer who wanted to make his own game based on a real-life hobby, beekeeping, used AI to build and publish one. He kept his real prompts, so you can see exactly what he asked. Click through the steps below.

One bit of jargon, since the example happens to be a game: an idle (or "incremental") game is one where numbers grow over time and you spend them on upgrades that make the numbers grow faster, think of it as a little economy you tend. That is the only game term you will need here. Josh's pitch for this one: "Start with one bee. End with a galaxy of bees." 🍯

Try it before you read on. This is A Billion Bees, the idle game Josh built. It opens in your browser, so there's nothing to download. Test it out, then come back to see how it was built.

Play A Billion Bees ↗

Who Did What

The most important thing for this course: this was not "the AI made a game." The work was split clearly between a person and two AI tools.

Josh (the human)

Supplied the idea, the taste, the direction, and the playtesting. Caught the AI's mistakes. Stayed in charge of the decisions throughout.

Claude (chat)

A support tool for design and balance: used to work through ideas, run the math, and keep a living design document.

Claude Code

A coding tool: used to turn the agreed design into actual game code and run it.

And the loop Josh repeated, over and over:

Follow the Build

Select a step to follow Josh's process. Where you see a chat box, that is a real message Josh saved.

Worth knowing: A Billion Bees is an early-development game. Josh built the first playable version in about three days (early June 2026) and is still adding to it, so what you play may look rough or change. That speed is part of the point: vibe coding can turn an idea into something playable fast, which is exactly why slowing down to check the AI's work, like Josh does below, matters so much.
Step 1 · Start from your own idea

A personal spark, scoped down to something you can finish

Josh did not begin with a prompt, he began with something he cares about. He is a gamer who wanted to make his own game, and he based it on a real-life hobby: he keeps bees. The catch: his real dream, a full beekeeping simulator, was far too big to actually finish. So he deliberately shrank it until it was something he could actually build and finish, a small incremental game.

  1. Josh, in his own words
    "I keep bees in real life, and what I really wanted to make was a beekeeping simulator. But that scope was way too large for a first project, so I kept shrinking the idea until it was something I could realistically build."

Takeaway: start from something you genuinely care about, then scope it down to something you can finish. The hardest part is resisting scope creep.

Step 2 · Make it run without you

The first "aha" of an idle game

The moment an idle game gets fun is when it starts working on its own. Josh added Auto-Tend, which automates the manual "tend the hive" tap. Automating away a chore is designed to feel like a promotion, not a loss.

Takeaway: Josh decided how it should feel; the AI worked out how to build it.

Step 3 · Make resets feel good

"Swarming": starting over, on purpose

Many idle games have a "prestige" step where you give up your progress for a permanent boost. Here it is swarming: you abandon your hive for permanent Queen Pheromones that make every future run faster.

Plain version: you press reset, but you keep a permanent reward, so starting over feels like leveling up, not losing.

Takeaway: good design makes a reset feel like progress. That judgment came from the human.

Step 4 · Borrow from real life

A beekeeping fact becomes a game mechanic

Real colonies swarm when the hive gets overcrowded, so Josh turned the reset into a "colony pressure" meter filling toward a breaking point. Before building it, he had the AI simulate it, which caught a problem: the obvious version would have locked the most-invested players out of swarming. Because it was caught in modeling, no code was wasted.

Takeaway: the cheapest place to catch a disaster is a simulation, not a published build. Make the AI show its work before it writes code.

Step 5 · The most important moment

When the AI was confident, fluent, and wrong

This step is worth reading slowly. Josh had piled up a strangely large number of points and asked the AI whether something was broken.

The setup, in plain wordsIn this game you collect points and spend them on upgrades. One kind of point is called Royal Jelly ("RJ" for short). Josh had collected a huge amount of it with nothing left to spend it on, and that felt off, so he asked the AI: is this a glitch, or is it normal? The catch: the answer depends on how long he had been playing, which the AI cannot see.
  1. Josh asks whether the big pile is a mistake or normal:
    "So I have like a gazillion RJ, is that expected for now, given that we dont have more stuff to spend on yet? feels like a lot"
  2. The AI answers in seconds, sounding sure:
    the AI's reply, summarizedIt calls it a bug and writes a long, confident explanation of what is "broken" and how to fix it.
  3. The catch: that confident answer only holds if Josh had just started playing, since early on a giant pile really would be odd. But he never said how long he had been playing, and the AI did not ask. It simply assumed he was a beginner, and it could not see his screen to check.
  4. Josh adds the one fact that changes everything, that he is about an hour in and already owns both upgrades:
    "So it snot a few minutes in, its probably close to an hour, I have both the RJ upgrades"
  5. The AI takes it all back ("diagnosis" just means its explanation of the problem):
    "That changes the diagnosis completely."
  6. There was no bug. An hour in, with both upgrades running, a big pile of Royal Jelly is exactly what is supposed to happen, Josh had simply collected more than the game lets him spend yet. Same pile of points, opposite answer, and the only thing that changed was one fact about Josh's situation the AI could not see.

Takeaway: sounding sure is not the same as being right. The AI used confident, technical language, but its whole answer rested on a guess about Josh's situation. When an AI sounds certain, check the assumptions underneath it, especially anything it assumes about you, your work, or what is on your screen, things it cannot actually see.

Go deeper: it happened twice

It happened once before, too. The AI guessed a reward was "stuck" paying too little, until Josh pointed out something only he knew.

  1. Josh explains the number was fine, he had left the game running overnight, so it had time to build up:
    "the first swarm got me 18 because it went overnight in offline mode and accumulated enough honey"
  2. The AI backs down again:
    summarizedWalks back its guess. Both times, the thing that settled it was a fact about Josh's own play the AI had no way to know.
Step 6 · Publish it, then listen

One real player beat a week of guessing

Josh posted an early test build, honestly tagged "AI-assisted" even though he was nervous about the stigma. Within about an hour, a real player replied, with praise and one precise question about locked content.

Takeaway: publish early and listen to real people. One honest comment is worth more than a week of internal guessing.

The Same Game, a New Look

Josh also redesigned the interface to make it more accessible. Flip the phone between the old interface and the new one that is live now.

Take a look at the interface progression.
(A recreation of the screens, not the live game.)

Built June 5, 2026

Showing the old version of the interface, built June 5, 2026.

Bugs You Only Catch by Playing

Some problems looked perfectly fine in the code and only showed up when a person actually played. Two examples worth knowing:

The "5.84 million honey" wall (published, then caught by playing)
Each worker bee cost 15% more than the last, fine for the first 20, catastrophic by 100, where one bee cost about 10 million honey for a tiny gain. The fix was not a rewrite, just a smaller number (about 6% instead of 15%) and letting hives carry the cost instead.
The wax multiplier (the scariest one)
A side resource called Wax was meant to be something you spend. Instead the code quietly let it act as a roughly 400-times multiplier on income, so the player's bees, the whole point of the game, became almost irrelevant while a side number secretly ran the economy. Nothing looked "broken"; it just played wrong. The fix was a rule, wax is spent, never multiplied, and Josh then had the AI build an automatic check that blocks that kind of bug from coming back, using the AI to guard against the AI's own mistakes.

A Note on the Art

Notably, none of the game's art is AI-generated. The visuals are geometric shapes drawn in code; Josh used no image or music generators at all. "AI-built" does not have to mean "AI-generated art", you can make deliberate, ethical choices about how AI is and is not involved in what you create.

What This Teaches About Working with AI

Josh's advice for students: start very small. Talk it through like a normal conversation, then have the AI write up a clear plan you can hold the work to. The hardest part is not letting the idea grow bigger than you can finish.

Go see for yourself: play A Billion Bees in your browser, then read its devlogA developer's log: short posts where a game's maker shares what they have been working on. and changelogA dated list of what was added, changed, or fixed in each new version. on the itch.io page to watch how it grew, update by update.

Who "Owns" an AI-Built Game?

Saying the decisions were Josh's is clear. Saying who legally owns the result is not, and it is one of the most contested questions in AI right now, worth understanding before you publish anything you make with AI.

The same low barrier has a real upside, too: it lets ideas and creators the big studios would never fund get made. Josh's hyper-specific beekeeping game is one small example, no studio would greenlight it. Others use these tools to tell overlooked stories: people with no game-dev background have built minigames about the lives of artists from refugee backgrounds, and a tradesman with no coding experience built accessibility-focused games for his young daughter, and for other players with cognitive and motor disabilities, projects a traditional publisher would rarely take on.

The law may stay unsettled for a while. But what made that father's games his was never the copyright, it was why he built them and the care he put in. That part is always yours. So do what Josh did: be plain about what the AI did, and keep the creative choices and the judgment about quality your own.

Knowledge Check

Select an answer to see feedback. Each option explains why it is or is not correct.

Question 1 of 3

When the AI confidently called the Royal Jelly pile "a bug," what actually made it wrong?

Question 2 of 3

Why did playtesting matter so much in this project?

Question 3 of 3

In Josh's process, where did the creative direction and judgment come from?

← Course menu