What is vibe coding?

Vibe coding is programming where the feedback loop runs through behaviour instead of source. You say what should happen, a model produces code, you run it, and you decide from the running program whether it is right. If it is wrong you describe what was wrong and go again.

The word "vibe" points at the acceptance criterion. A traditional review asks whether the code is correct by inspection. Vibe coding asks whether the thing does what you wanted. These are not the same test and they fail in different places.

Using a model to write code you then read carefully is not vibe coding. That is assisted programming, and it is a different and older practice. The distinguishing feature here is that reading the code is not part of the loop.

It works where behaviour is fully observable. Game logic is the clearest example: if the door opens when it should, the door code is right, and there is nothing hidden behind that observation.

It works where the cost of being wrong is low and the cost of iteration is low. Trying five versions of how combat feels is a different activity when each version is a sentence rather than an evening. You test ideas you would otherwise have argued yourself out of.

And it works where you have real taste about the output. Judging a running game is a skill most people have without training, which is why games turn out to be one of the better fits for the method.

It fails where correctness is not visible from the outside. Security, money, data integrity, anything with an edge case you will not stumble into by playing. A payment path that works in every case you tried is not a payment path that works.

It fails on structure. Code written sentence by sentence over weeks accumulates a shape nobody chose. Everything still works and every new change costs slightly more, and there is no single moment where it went wrong.

And it fails on anything with taste in the shape rather than the behaviour. A world, a level, a layout. You can describe a valley to a model and get a valley. Getting the valley you actually meant, by description alone, takes longer than shaping one with your hands, and the intermediate results are almost right, which is the hardest thing to fix.

Games split cleanly along the line above, which is unusual and useful. The behaviour half — rules, state, triggers, movement, inventory, dialogue flow — is nearly ideal for the method. You can see whether it is right by playing.

The world half is nearly the worst case for it. There is no correctness test for a landscape, only whether it is the one you wanted, and a model cannot know that from a sentence.

So the sensible arrangement is not "vibe code the whole game" or "do not vibe code". It is to vibe code the part that is behaviour and build the part that is a world.

Stage Engine is built on exactly that split. Director 1 writes GDScript into your project when you describe behaviour, and you never have to read it. The world is built by hand in a builder — terrain, water, weather, buildings, characters — with a mouse rather than a sentence.

The engine underneath is Godot, open source, bundled inside a desktop app for Mac and Windows. The game runs locally on that copy of Godot, so the loop of change, play, judge is as fast as your machine.

Being non-technical means you do not write the code. It does not mean you cannot judge the result, and in vibe coding the judgement is the entire mechanism. Building needs an internet connection; playing what you built does not.