Vibe coding a game
Vibe coding is accepting code you have not read. In most software that is a gamble. In a game it is defensible, for one specific reason.
Jump to a section
Vibe coding is describing what you want, accepting the code without reading it, and judging the result by whether it behaves. For most software that is a bad trade. For a browser game it is a reasonable one, because the output is something you can play, and a game that is wrong is obvious within seconds.
You are allowed to not read the code. You are not allowed to not play the game. The moment you accept a change without trying it, you have stopped vibe coding and started hoping.
Why a game is the safest thing to build this way#
Think about what you give up by not reading code. You lose the ability to notice that a calculation is subtly wrong, that an edge case is unhandled, that a value is never cleared. In a spreadsheet tool those faults sit quietly for months.
In a game they are visible. A wrong calculation makes something move badly. An unhandled edge case makes the player fall through the floor. A value that is never cleared means your score does not reset. You do not need to read the file to find any of that. You need to play for two minutes.
That is the whole argument, and it is worth being precise about it, because it does not extend to anything with a database, a payment or somebody else's data in it.
The method, in four steps#
One screen, one thing the player does, one way to lose. Ask for a single HTML file so there is nothing to install and nothing to configure.
Not skim the code. Play. Two minutes, badly, on purpose. You are looking for the gap between what you imagined and what exists.
The jump feels like it happens a moment after I press. That gets a better result than naming a variable, because you are describing the thing you can see and it is describing the thing it can see.
Before any large change, keep a copy. This is the one piece of discipline the method actually requires, and it is what stops a bad afternoon costing you the whole game.
Build a complete browser game as ONE self-contained .html file I can
double click. No frameworks, no build step, no image files.
THE GAME: <one sentence. A verb and a way to lose.>
Make it playable in the first version. I would rather have something
rough that runs than something half built that does not.
TECHNICAL, keep all of these:
- Movement based on seconds elapsed between frames, capped at 0.05, so
the speed is the same on every screen.
- canvas { touch-action: none; } in the CSS, and it must work on a phone.
- Every number I might want to change gathered into one CONFIG object
at the top, with a short comment on each.
When you are done, tell me in three lines what I should try first in
order to break it.The last line is the one that matters here. It turns the model into the person who writes the test plan, which is the job you are choosing not to do yourself.
The three ways it goes wrong#
None of these are about the model being bad at code. They are about what happens to a file nobody is reading.
The silent regression#
You ask for a change to the jump. The jump improves. Something unrelated stops working, and because you only tested the jump, you do not notice for an hour. By then you have made four more changes on top of it and cannot say which one did it.
The fix costs nothing: play the first thirty seconds of the game after every change, not just the part you changed.
The rewrite spiral#
A fault survives two attempts, so the model rewrites a larger piece of the file to approach it differently. Now the thing that was wrong is gone and three things that were right are also gone. Repeat twice and you are further from working than you were an hour ago.
When a fault survives two tries, stop asking for a fix. Go back to the saved copy and describe the fault differently instead.
The file you can no longer change#
After forty messages, a file nobody has read becomes a file nobody can reason about, including the model, because the structure was never anybody's decision. Changes start costing more than they did at the start, which is the opposite of how a project is supposed to go.
Asking for structure up front is what prevents this, and it is why the prompt above asks for a CONFIG object. A file with its numbers gathered in one place stays changeable far longer than one without.
Keeping control without reading the file#
- One change per message. Two at once and you cannot attribute either the improvement or the damage.
- Ask what it changed, in one sentence. Not the code, the summary. If the answer mentions files or systems you did not ask about, play more carefully before you continue.
- Keep CONFIG readable even if nothing else is. Twenty lines of named numbers is a description of the game that you can actually audit.
- Name versions by what they do. game-jump-feels-right.html beats game-7.html when you are trying to find your way back on Sunday.
🌊Games built this way, with the prompt behind each
Fable 5.1
GPT-6.1 SolCommon questions#
What is vibe coding?
Building software by describing what you want and accepting the code without reading it, judging the result by behaviour instead of by review. The phrase was coined for the practice of leaning entirely on a model and only checking whether the thing works.
Is vibe coding a good way to make games?
Better than for almost anything else, because the output is playable and faults show themselves. It is a poor way to build anything whose output merely looks plausible, and a bad idea for anything holding other people's data or money.
Do I need to know how to code to vibe code a game?
No, but you need to be able to describe behaviour precisely and to read an error message well enough to paste it back. That is an afternoon of learning rather than a skill you have to acquire first.
Why does my game get worse the more I ask for?
Usually the rewrite spiral. A fault survives two attempts, the model restructures to attack it another way, and working behaviour is lost alongside the broken behaviour. Go back to a saved copy and describe the fault differently rather than asking again.
How do I stop breaking things I already fixed?
Play the first thirty seconds after every change, not only the part you changed, and keep a copy of any version you were happy with. Those two habits catch almost all of it and neither requires you to read any code.
Can I publish a game I did not write myself?
Yes, and the game page here records the model and the prompt behind it, so how it was made is part of the listing rather than something to hide. What you cannot do is name it after somebody else's game.
Where to go next#
For the shape of the file you are not reading, the one-file skeleton is forty lines and worth ten minutes. For prompts that produce a finished game rather than a sketch, use the prompt guide.
If you need an idea sized to one evening, the ideas list has twelve with the hard part named. When yours is worth someone else's time, publish it.
Built something? Put it on Agent Games.
Publishing takes a file and a minute. Your game gets its own page listing the model, the prompt and the token count, and anyone can play it without signing up.
Read next