What is vibe coding and how to do it without a computer science degree? You need an idea, an AI coding tool and the patience to test what it builds, and getting started is easier than you might think. This guide covers where the term came from, what actually happens when you vibe code, a six-step process you can follow tonight, and a worked example that builds a small browser game from a handful of prompts. It finishes with the mistakes that sink most first projects.
What does vibe coding mean?
Vibe coding means building software by describing it in everyday language to a large language model (LLM, the kind of AI behind modern chat assistants), which then writes the source code for you. Computer scientist Andrej Karpathy coined the term in February 2025. His idea was that you give in to the flow, judge the program by how it behaves, and mostly stop caring what the code looks like. By March 2025 Merriam-Webster had listed it as a slang and trending expression, and Collins English Dictionary named it its Word of the Year for 2025.
The key difference from ordinary AI-assisted programming is how much you read. A professional using an AI autocomplete still reviews every line. A vibe coder often accepts the output without reading it closely, runs it, and steers with follow-up prompts like “the jump feels floaty, make it snappier.” You judge the result, not the code.
The idea is older than the name. Vibe coding is a modern form of natural language programming, where you tell the computer what you want in human language and don’t need to understand how the code works. What changed is that LLMs became good enough to make that practical. Not everyone loves the label: in June 2025 Andrew Ng argued it misleads people into thinking engineers just “go with the vibes.” For the backstory, see our piece on Andrej Karpathy and the origin of vibe coding.
How does vibe coding actually work?
Every vibe coding session runs the same four-part loop, whatever tool you use:
- Describe. You write a prompt (the instruction you give the AI) saying what you want built or changed.
- Generate. The model writes or edits the code.
- Run. The program runs, either automatically in the tool or by you clicking a button.
- Feedback. You try it out and describe what’s wrong, missing or not quite right. Then the loop starts again.
Modern tools add an agent on top of this. An agent is an AI that doesn’t just reply with text: it can take actions like creating files, running the program, reading error messages and fixing its own mistakes before handing the result back to you. That’s why vibe coding now feels much less like copying code out of a chat window and much more like giving instructions to a junior developer who works very fast.
So what is your job in the loop? You’re the product owner and the tester. The AI handles syntax (the exact spelling and grammar of a programming language). You handle intent: what the thing should do, whether it does it, and what “done” looks like. Beginners who understand this split get far better results than those who expect the AI to read their mind.
What is vibe coding and how to do it, step by step
Here is the practical half: how to do it. This six-step process works for apps, tools and games alike.
Step 1: Pick an idea you can finish in an evening
Your first project should fit on one screen. A dodge game, a pomodoro timer, a flashcard quiz. Big ideas like “an open-world RPG” fail because the AI has to make hundreds of design decisions you never stated, and every one is a guess.
Step 2: Write a short spec before you prompt
A spec (short for specification) is a few lines describing what the thing does, who controls what, and what counts as winning or finishing. Microsoft’s introduction to vibe coding module teaches the same habit: use the AI to draft product requirements and wireframes (rough layout sketches) before generating the app itself. Five bullet points is enough.
Step 3: Choose one tool and stick with it
Pick a general chat assistant, an editor-based coding agent or a purpose-built engine (compared in the table further down). Switching tools mid-project loses context, meaning everything the AI knows about your project so far.
Step 4: Ask for the smallest working version
Your first prompt should ask for a playable skeleton, not the finished product. “A player square that moves left and right, red blocks falling from the top, game over on contact” beats a page-long wish list.
Step 5: Test, then change one thing per prompt
Run it. Play it. Then describe exactly what you saw: “When I hold the left arrow the player keeps moving after I let go.” One change per prompt makes it obvious which change broke something. If you bundle five requests together and the game breaks, you won’t know which one caused it.
Step 6: Save every working version
When the project works, save a copy before the next change. Developers do this with version control (software such as Git that records snapshots of your project), but a dated folder copy is fine for a beginner. Being able to roll back is what turns a broken project into a minor setback.
A worked example: vibe coding a small browser game
Let’s run the process on a real project: a single-screen dodge game built with Phaser, a popular open-source JavaScript framework for browser games. Here’s the prompt sequence:
- “Make a Phaser 3 browser game, 480 by 640. A blue square player moves left and right with the arrow keys. Red squares fall from the top at random positions. Touching one ends the game.”
- “Add a score that goes up by one every time a red square leaves the bottom of the screen.”
- “Show ‘Game Over’ in the middle of the screen when the player is hit.”
After those three prompts, a good model will produce something close to this. It uses plain rectangles instead of art, so you can paste it into any page that loads Phaser 3 and play straight away:
const config = {
type: Phaser.AUTO,
width: 480,
height: 640,
backgroundColor: '#1d1f2e',
physics: { default: 'arcade' },
scene: { create, update }
};
let player, cursors, rocks, scoreText;
let score = 0;
let gameOver = false;
function create() {
player = this.add.rectangle(240, 590, 40, 40, 0x5ad1ff);
this.physics.add.existing(player);
player.body.setCollideWorldBounds(true);
cursors = this.input.keyboard.createCursorKeys();
rocks = this.physics.add.group();
scoreText = this.add.text(12, 12, 'Score: 0', { fontSize: '20px', color: '#ffffff' });
this.time.addEvent({
delay: 600,
loop: true,
callback: () => {
if (gameOver) return;
const x = Phaser.Math.Between(20, 460);
const rock = this.add.rectangle(x, -20, 30, 30, 0xff6b6b);
rocks.add(rock);
rock.body.setVelocityY(Phaser.Math.Between(180, 320));
}
});
this.physics.add.overlap(player, rocks, () => {
gameOver = true;
this.physics.pause();
this.add.text(240, 320, 'Game Over', { fontSize: '40px', color: '#ffffff' }).setOrigin(0.5);
});
}
function update() {
if (gameOver) return;
player.body.setVelocityX(0);
if (cursors.left.isDown) player.body.setVelocityX(-300);
else if (cursors.right.isDown) player.body.setVelocityX(300);
rocks.getChildren().slice().forEach(rock => {
if (rock.y > 680) {
rock.destroy();
score += 1;
scoreText.setText('Score: ' + score);
}
});
}
new Phaser.Game(config);You don’t need to understand every line to vibe code, but skim it once. You’ll spot plain-English clues: delay: 600 controls how often blocks spawn, setVelocityX(-300) sets player speed. Knowing where the knobs are lets you write sharper prompts, like “spawn blocks every 400 ms after the score passes 20.”
Notice the small detail in .slice(): it copies the list before removing blocks from it. Without it, deleting items while looping skips some of them. That’s a classic bug that AI models sometimes produce and sometimes avoid, and a good reminder that testing beats trusting.
Next prompts might be: “Restart when I press Space after game over,” “Make blocks fall faster as the score rises,” and “Add a high score saved in the browser.” Same rules apply: one change, then test.
