What Is Vibe Coding? (And Why It's Eating Indie Game Dev)

Vibe coding is the practice of building software by describing what you want in natural language and steering an AI agent toward it through feel — not specs. The phrase started as a joke and ended up describing the thing most indie game developers actually do now. This is what vibe coding is, why it’s eating indie game dev specifically, and how a vibe-coding session for a real playable game actually unfolds.

What vibe coding actually is

• Vibe coding is iterating on software through natural-language prompts and feel-based steering, with an AI agent doing most of the typing.
• The agent owns the implementation. You own taste, direction, and stop-conditions.
• It’s eating indie game dev first because games are the workload where “does it feel right?” is more useful than a unit test.
• Done well, you ship a real, playable game in an afternoon. Done badly, you produce a pile of half-broken scenes you can’t debug.
• The right tool for vibe coding a game in 2026 is something with a tight prompt → preview → feedback loop. We built WizardGenie for exactly this — described here.

Where vibe coding came from (and why the name stuck)

The phrase “vibe coding” started circulating in early 2025 as developers noticed that long sessions with frontier AI agents felt less like programming and more like jazz. You aren’t writing the code. You aren’t even fully specifying it. You’re nudging the agent — “snappier”, “tighter”, “feels too floaty” — and the agent translates that into actual code changes.

The phrase landed because the description was honest. The traditional software-engineering frame — gather requirements, write specs, design, implement — doesn’t match what you’re doing. You’re doing something closer to taste-based iteration on a black-box implementation. That’s the vibe in vibe coding: a feedback signal that doesn’t need to be formal to be useful.

Critics initially treated it as a slur. The implication was supposed to be that the practitioner doesn’t actually understand the code — that vibe coding produces software a junior engineer can’t maintain. That criticism is real, but it isn’t the death blow people expected. It’s a constraint on what vibe coding is good for, not a refutation that it works.

Vibe coding vs. spec-then-code (and why the old way doesn’t fit games)

Traditional software engineering is built on the assumption that the requirements can be made explicit before implementation. Specs first, code second. Tests verify the spec. It works because most software has external definitions of “correct” — a tax calculator that returns the wrong number is broken; an inventory system that loses items is broken.

Games have no equivalent. “Correct” is replaced by “fun”, and fun has no specification. You can describe target outcomes (“the player should feel powerful when they pick up the fire-rune”), but you can’t write a unit test that proves you got there. The only verification is that you play it and it feels good. That makes the spec-first frame actively unhelpful: the spec you’d write before the first prototype is wrong because you don’t know yet what feels right.

This is why vibe coding hits indie game dev hardest. The traditional discipline says “design before you code.” Game design has spent fifty years admitting that doesn’t work — every studio runs prototypes early and iterates on game-feel. Vibe coding just compresses the prototype-iterate loop from weeks to minutes by letting an AI agent handle the typing.

The anatomy of a real vibe-coding session

What does an actual vibe-coding session look like for a small game? Here’s a session we ran in WizardGenie targeting a 2D platformer with magic. Forty-three minutes start to finish, ending with a playable build.

• Minute 0 — opening prompt: “Build a 2D platformer in Phaser 3 with a wizard who throws fireballs. Three platforms, a death pit, a score counter.” Model: GPT-5.5 (sharp at scaffolding).
• Minute 2 — first playable: Browser preview shows the wizard, the platforms, and a working fireball. The slimes are too big and the fireballs feel weak.
• Minute 4 — vibe correction: “Fireballs feel weak. Make them faster and add a tiny screen shake on hit.” Agent edits the player controller and adds a Phaser camera shake. Done in one turn.
• Minute 9 — direction shift: “Actually, what if the fireballs ricochet off platforms once?” Bigger change. Switch to Claude Opus 4.7 because the bouncing logic touches the physics body and needs careful reasoning.
• Minute 13 — back to fast iteration: Swap to DeepSeek V4 Pro for a sequence of small tweaks: jump height, gravity, slime damage values. Cheap, fast, no design decisions.
• Minute 28 — game-feel pass: “It’s fine but it’s not fun. The wizard’s movement feels glued to the ground.” Back to Opus to diagnose. It identifies acceleration is too high and adds a small coyote-time window.
• Minute 43 — ship: Final tweaks to the score display and a fireworks effect on level complete. Build is playable, fun, and roughly 800 lines.

What’s worth noticing: the spec for the finished game does not exist anywhere. There is no design document. The closest thing is the chat history. That’s the load-bearing observation about vibe coding — the design is co-authored with the agent in real time, encoded in the sequence of nudges, and visible only by reading the transcript backwards.

Why vibe coding is eating indie game dev specifically

Several factors make games the workload that this practice fits cleanest:

1. The feedback loop is visual and immediate. A vibe-coded React app needs end-to-end tests to know if it works. A vibe-coded platformer just needs you to press space and try to jump. The cycle time from change to evaluation is seconds.
2. “Correct” is “fun”, which can only be felt. Vibe coding’s weakness — that you can’t verify against a spec — is a non-issue when the spec doesn’t exist anyway.
3. Game frameworks are well-trained. Phaser 3, Three.js, p5.js, and pico-8 each have enough public code on the internet that frontier models know them deeply. The agent isn’t learning the API on the fly; it’s pattern-matching from training data.
4. Indie scale matches AI agent capability. A typical jam game is under 2,000 lines. Frontier coding models hold projects of that size end-to-end without losing track. Above ~10,000 lines vibe coding starts breaking, but a huge fraction of the indie market lives below that line.
5. Asset generation is now in the same loop. Sprites, music, sound effects, and 3D models can be generated from prompts on the same surface where the code is being written. Vibe coding stops being just code — it becomes a single conversation that emits a complete game including art and audio.

What vibe coding can’t do (and what to do about it)

Three real limitations are worth being honest about:

• Maintainability decays past a project size threshold. Once a game gets past about 3,000 lines, the agent starts losing track of conventions you’ve adopted, and you start losing track of what the agent did. The fix isn’t to abandon vibe coding; it’s to switch modes — vibe-code small components, then read what the agent wrote and refactor with intent.
• Subtle bugs are hard to surface. Vibe coding is excellent at producing code that runs; it’s less reliable at producing code that’s correct under edge cases. For game-dev this is usually fine — a slightly-off jump arc isn’t a crash. For anything that touches money, accounts, or persistence, you need a real engineering pass.
• You eventually need taste. The best vibe-coded games come from people who can tell when the agent has produced something flat. That ability isn’t free; it’s developed by playing a lot of games and paying attention. Vibe coding doesn’t replace game design instincts — it just makes them the bottleneck.

Tools that make vibe coding actually work

The right tooling collapses the prompt → preview → feedback loop. Three properties matter:

1. Live preview that matches what you’re building. If you’re building a 2D platformer, the preview window should run the platformer. If you’re building a 3D scene, it should render the scene. Toggling between a code editor and a separate run script destroys the loop.
2. A model picker, not a single locked-in model. Vibe coding wants the cheap fast model for trivial edits and the frontier model for design decisions. You should be able to switch per turn. WizardGenie’s picker exists for exactly this — eight models, switch instantly, context preserved.
3. Asset tools on the same surface. When the agent says “I added a slime placeholder rectangle,” you want to be one prompt away from a real slime sprite, not in a different tab uploading a file. Tools like Auto-Sprite v2, 3D Studio, and the rest of the Sorceress kit live in the same place WizardGenie does so the asset pipeline doesn’t break the vibe.

How to start vibe coding a game right now

The fastest path: open WizardGenie, type a one-sentence game idea, and let the agent scaffold it. Free trial uses DeepSeek V4 Flash with a generous token allowance — enough to get a playable build. After that you bring your own API key for any of eight frontier models. No install, no setup, no IDE configuration.

Practical opening prompts that work well:

• “Build a 2D platformer in Phaser 3 where you play as a [character] who [verb]. Three levels, a score counter, a win condition.”
• “Build a top-down survival game in Three.js where the player gathers [items] before night falls. Day/night cycle, hunger system, simple inventory.”
• “Build a roguelike dungeon crawler with procedural levels, three enemy types, and one boss room. Single HTML file.”

Each of those produces a playable scaffold in under two minutes on a frontier model. Everything after that is steering. That’s the loop.

Vibe coding isn’t going to remain a niche or an indie thing. The shift from spec-first to taste-first will spread to everything where “correct” is fuzzier than “passes a test” — which is more software than people think. But indie game dev is where it landed first, and it’s the workload where it’s most clearly winning right now.