Vibe Coding Game Development: What AI Can Take Over
Vibe coding can take over most of the typing in game development, but it does not make the game for you. Design, feel and deciding what to cut stay with you, while the AI writes and changes the code.
Who does which job?
A game is more than code. Here is every job in an invented small game where you run a lighthouse: you ration oil, keep the lamp turning and sound the horn so ships do not hit the rocks.
| Job | Who does it | In the lighthouse game |
|---|---|---|
| Rules | You | You decide that oil burns faster in fog |
| Code | AI | All of it, on your instructions |
| Balance | Both | The AI suggests numbers, you play and adjust |
| Art | Your choice | The AI can start with plain shapes, and you decide what the final look is and note where it came from |
| Sound | Your choice | The horn must be heard over the storm, and you only know that by listening |
| Finding bugs | Both | You spot it in play, the AI looks for the cause |
| Testing with people | People | Only a stranger can show you that nobody understands the oil gauge |
| Store text | Both | The AI drafts, you make sure it is true |
| Cutting things | You | The AI will happily build a fourth ship type if you ask |
The last row matters most. Your AI rarely says "this is too much". Saying that is your job now.
What makes games harder than other software?
Games have three problems that a simple website does not.
Feel does not show up in the code. If the lamp takes 0.4 seconds to answer your key, the rules are correct and it still feels sluggish. Your AI cannot feel that delay. You have to play it and say so.
Everything touches everything. Fog changes the oil, oil changes the lamp, the lamp changes the ships. A small change to fog can sink more ships an hour later. So have your AI draw what feeds what before it builds, and see why games keep breaking.
Games take time to reach their problems. A bug in the third storm only shows after twenty minutes of play. So ask for a shortcut, such as a key that jumps straight to the third storm. Remove it before you publish.
What should I decide first?
Choose a game whose hard parts you are good at. If you can write but not draw, the lighthouse game could be nothing but text and a radar screen. If you have an ear for music, build around sound. The AI covers the typing, and everything else in the table above still takes your time.
For the mechanics themselves, Spielerando can fill a gap in that table. Through an MCP connection your AI gets its blueprints, ready-made code and wiki, so common things do not start from a guess. You can join for nothing through Google or e-mail. It leaves your game and code alone. See how it connects.
Paste this to your AI
Here is my game idea: [two sentences].
Go through these jobs one by one: rules, code, balance, art, sound, finding bugs, testing with people, store text, cutting things. For each one, say what you can do, what I have to do myself, and what you cannot judge at all, such as how something feels to play.
Base each answer on what is really in my idea or my project, and name the part you mean. Where you have nothing to go on, write "nothing to go on yet" and ask me one question. Do not fill the gap with a general tip.
Then map what feeds what in my game as a Mermaid diagram, such as one resource changing another. Walk through it and mark the loop most likely to go wrong. Whatever we build next gets built from that diagram.
End with the three jobs that will take me the longest, and say why you think so.
Or skip this and connect the MCP: your AI then finds all of this by itself.Connect the MCP
How to check it worked
- Count the gaps. If "nothing to go on yet" never appears, the AI filled the holes with general advice. Ask it to try again.
- Question any job it claims for itself. Ask: "How would you know you got that right?"
- Follow one loop on the diagram. Does the game really do that when you play?
- Give a stranger ten minutes. Do they understand the game without your help?