Vibe Coding Tips and Tricks: 9 That Save Real Time
The vibe coding tricks that save the most time are small habits, not clever wording: look before you build, see what the game is doing, and start over sooner. Here are nine, shown on an invented mini golf game set inside a bottle garden, where the ball rolls over moss and bounces off glass.
Before you build
1. Ask for three options first. "Give me three ways the ball could behave on moss, one sentence each. Do not build yet." Reading three sentences takes a minute. Throwing away a build takes far longer.
2. Let the AI interview you. The Claude Code docs suggest this for when you do not know exactly what you want: ask it to question you until it could write the plan down. It will ask about things you had not thought of, such as what happens if the ball leaves the bottle.
3. Keep a "nope list". One file with everything you have already turned down: no ball trail, no timer, no talking gnome. Ask your AI to read it at the start of each chat, so you stop saying no to the same idea.
While you build
4. Add a slow-motion key. At quarter speed you can watch the ball pass through the glass, instead of arguing about whether it did.
5. Put numbers on the screen. Show the ball's speed and what surface it is on. "Speed stays at 0.2 and never reaches zero" gives your AI far more to work with than "the ball will not stop".
6. Ask for sliders. A slider for moss friction lets you try twenty values in a minute without sending twenty messages. This is the best trick on the list for anything that has to feel right. Remove the panel before you publish.
7. Paste a screenshot. The Claude Code docs list a pasted screenshot of the design or the error as a way to give it what it cannot see. A picture of the ball stuck in a corner beats a paragraph about it.
When it goes wrong
8. Two strikes, then start over. The same docs warn that one more correction mostly piles onto two failed attempts already sitting in the chat. Their advice is to clear the chat and write one better message that includes what you learned. Do that with a game too: it feels slower and it rarely is.
9. Ask for the evidence, not the verdict. The docs tell you to ask for the command it ran and what came out, or the screenshot, because a bare claim that everything passed tells you very little. For a game, that means asking "what did you do to find that out?"
Which trick should I start with?
Number 6, if your game has anything that moves. Number 3, if you keep having the same argument with your AI. Number 8, if you have just spent an hour on one bug. If that hour is already behind you, read the repair guide.
Sliders go well with small ideas such as the extra moment after a ledge, where a difference you can hardly measure decides how fair a jump feels.
Paste this to your AI
Add a small helper panel to my bottle garden golf game, only for me while I build it. It opens with the T key.
It shows, live: the ball's speed, the surface it is on, and how many times it touched the glass. It has sliders for moss friction, bounce and gravity, and a button for quarter speed.
Keep the panel apart from the game, so that I can remove it in one step before I publish.
Before you add anything, sketch the ball's life in Mermaid: rolling, bouncing, slowing on moss, stopping. Check that it can always reach stopping, then build the panel from that sketch.
Then tell me where each number in the panel comes from in the game. If the game does not really track something and you had to estimate it, mark that number as an estimate so I do not trust it by mistake.
Or skip this and connect the MCP: your AI then finds all of this by itself.Connect the MCP
How to check it worked
- Press T. Does the panel open and close without changing the game?
- Move one slider a lot. Does the ball change right away?
- Let the ball stop. Does the speed read zero, as the sketch promised?
- Use quarter speed on a wall hit. Can you see the bounce clearly now?
- Ask for the panel to be removed. Does the game still play the same? Then bring the panel back.