Andrej Karpathy Vibe Coding: Origin, Meaning and Limits

The Andrej Karpathy vibe coding idea started as one social media post in February 2025 and turned into one of the most argued-about terms in software within a year. Karpathy, a co-founder of OpenAI and former AI leader at Tesla, described a way of building where you tell an AI model what you want, accept what it writes, and judge the result by running it instead of reading the code. Below: what he actually meant, why the term spread so fast, where it breaks, and how to use it to ship a small game without losing control of your project.

The Andrej Karpathy vibe coding post, explained

Karpathy’s post described a new kind of coding where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists,” as Wikipedia’s entry on vibe coding records. The tool doing the work is a large language model (LLM): an AI trained on huge amounts of text and code that can write working programs from plain-English requests.

The post walked through his own workflow, and it was deliberately loose:

• He spoke his requests out loud to an AI code editor instead of typing them.
• He accepted every change the AI suggested without reading the diff (the line-by-line list of what changed in the code).
• When an error appeared, he pasted the error message back to the AI with no comment and let it fix things.
• When a bug wouldn’t go away, he asked for changes until it did, or worked around it.

The part people skip is the scope. He framed this as fine for throwaway weekend projects, the kind of thing you build for fun and never maintain. It wasn’t a proposal for how to run a bank’s codebase. It was an honest description of what it felt like to build small things once the models got good enough.

The idea also had a history. In 2023 Karpathy had said that “the hottest new programming language is English,” meaning LLMs had become capable enough that you could command a computer in natural language. The Andrej Karpathy vibe coding post was that claim put into practice: if English is the programming language, then reading the generated code is optional, at least for toys.

What does vibe coding mean in practice?

Stripped down, vibe coding is a four-step loop:

1. Describe. You write or say a prompt (the instruction you give the AI), for example “make the player jump higher and add a double jump.”
2. Generate. The model or a coding agent (an AI that can edit files, run commands and try again on its own) writes or changes the code.
3. Run. You play or use the result.
4. React. You describe what’s wrong or what you want next, and the loop repeats.

What makes it vibe coding is step 3 replacing code review. You judge the software by its behaviour, not by its source. That’s the line between vibe coding and the broader field of AI-assisted software development, where a developer uses AI suggestions but still reads, understands and owns every change.

Approach	Who writes the code	Who reads it	Best for
Traditional coding	You	You and your team	Long-lived products, engines, anything critical
AI-assisted development	AI drafts, you edit	You, every change	Professional work, shipped games
Vibe coding (Karpathy’s sense)	AI	Mostly nobody	Prototypes, jam games, personal tools

In real projects people slide between these modes. You might vibe code a level editor you’ll throw away, then switch to careful review when you touch your save system. Knowing which mode you’re in at any moment is most of the skill.

Why the term spread, and who pushed back

The phrase named something lots of people were already doing, which is why it caught on. Merriam-Webster listed it as a “slang & trending” expression in March 2025, and Collins English Dictionary made it Word of the Year for 2025. The same month, Y Combinator reported that 25% of startups in its Winter 2025 batch had codebases that were 95% AI-generated.

Non-programmers were early adopters. New York Times journalist Kevin Roose built several small apps this way and called them “software for one,” tools made for an audience of one person. He also said the results were often limited and error-prone. By July 2025 the Wall Street Journal was reporting that professional engineers had adopted vibe coding for commercial work, and in January 2026 Linus Torvalds said he had vibe coded a Python visualiser for a hobby audio project because his Python knowledge was limited.

Not everyone liked the label. In June 2025 Andrew Ng argued it misleads people into thinking engineers simply “go with the vibes” when they use AI tools, when in practice good AI-assisted work takes a lot of deliberate effort. By early 2026, a year after the original post, tech coverage reported Karpathy himself preferring the term “agentic engineering” for the supervised, professional version: AI agents do the typing, humans still own the design and the review.

That shift matters if you’re learning. The Andrej Karpathy vibe coding style is a real, useful mode. It just isn’t the whole job once a project gets big.

Where vibe coding breaks

The criticisms are specific and backed by data, so it’s worth knowing them before you rely on the method:

• Security. In May 2025, 170 of 1,645 web apps built with the vibe coding platform Lovable were found to have a flaw that let anyone access personal information. A Veracode study in October 2025 found LLMs had become much better at producing working code over three years, but no better at producing secure code.
• Code quality. A December 2025 analysis by CodeRabbit of 470 open-source pull requests found AI co-authored code had about 1.7 times more major issues than human-written code, including logic errors and security vulnerabilities.
• Agents acting on their own. In July 2025, the founder of SaaStr described how Replit’s AI agent deleted a database despite explicit instructions not to change anything.
• Maintainability. Code nobody has read builds up technical debt, which means shortcuts that make every future change slower and riskier. Simon Willison’s point, roughly: most real engineering means changing systems that already exist, and that depends on code someone understands.

For game developers the risk profile is a bit different. A single-player browser game with no accounts has very little to leak. Your main danger is the second and fourth bullets: on day three of a jam, the codebase is a tangle the AI keeps breaking while it fixes something else. Once you add online leaderboards, logins, payments or saved user data, the security bullets apply to you too, and that code deserves a real review.

Vibe coding a game with WizardGenie

General-purpose coding agents can build games, but they don’t know what a game is. You end up explaining the setup, wiring up a preview, and pasting errors back and forth, the same chores Karpathy described. A game engine handles the parts every game needs (rendering, input, physics, the game loop), so an AI working inside one starts from a better place.

WizardGenie is the AI-native game engine at the heart of Sorceress, and it’s built around exactly the loop from the Andrej Karpathy vibe coding post. You describe the game you want, and WizardGenie writes it, runs it and iterates on it in real time. The describe, generate, run, react cycle happens in one place instead of across an editor, a terminal and a browser tab.

A few things matter for how you vibe code with it:

• Model choice is yours. WizardGenie drives every leading AI coding model, and you can switch between them freely with your own API key. If one model keeps getting stuck on a bug, try another on the same project.
• Web or desktop. It runs in the browser at /wizard-genie/app with nothing to install, and as a Windows desktop app with an auto-updater. The desktop app gives you native file access and longer agent sessions, which helps once a project grows past a quick prototype.
• Assets in the same suite. Placeholder rectangles are fine for testing mechanics, but a jam game needs art and sound. Auto-Sprite v2 (Pro) creates game-ready 2D sprites, such as characters, items and effects. Sound Studio covers AI music, SFX and voice. If you work in another coding agent, the Sorceress API gives it one key to generate sprites, 3D models, rigs, animation, music and SFX.

The WizardGenie overview covers the engine itself, and the Sorceress tools guide maps every asset tool if you want to see the whole pipeline.

A worked example: a one-evening platformer

Here’s how a disciplined version of the Andrej Karpathy vibe coding loop looks for a small platformer. The rule: one change per prompt, and play after every change.

1. Start with the core verb. “Make a side-view platformer. The player is a yellow rectangle that moves with the arrow keys and jumps with up. Add a ground and three floating platforms.” Play it. Does jumping feel right?
2. Tune the feel in numbers. Vague prompts like “make it feel better” produce random changes. Say “increase jump height by about a third and reduce gravity slightly.” Play it again.
3. Add one system at a time. Coins, then a score display, then one enemy that patrols a platform. Test each before moving on.
4. Swap in real art late. Generate a character with Auto-Sprite v2 once the mechanics work, so you don’t polish art for a game you’ll redesign.
5. Read the core once. Before the game gets bigger, ask the AI to show you the player movement code and explain it. You don’t need to read everything, just the heart of the game.

Step 5 is where beginners learn the most. Whatever engine or framework your AI uses, the core of a platformer looks a lot like this example in Phaser, a popular browser game framework:

const config = {
  type: Phaser.AUTO,
  width: 800,
  height: 600,
  physics: { default: 'arcade', arcade: { gravity: { y: 600 } } },
  scene: { create, update }
};

let player, cursors;

function create() {
  const ground = this.add.rectangle(400, 580, 800, 40, 0x334455);
  this.physics.add.existing(ground, true); // true = static body

  player = this.add.rectangle(400, 300, 32, 48, 0xffcc00);
  this.physics.add.existing(player);
  player.body.setCollideWorldBounds(true);

  this.physics.add.collider(player, ground);
  cursors = this.input.keyboard.createCursorKeys();
}

function update() {
  const speed = 200;
  if (cursors.left.isDown) player.body.setVelocityX(-speed);
  else if (cursors.right.isDown) player.body.setVelocityX(speed);
  else player.body.setVelocityX(0);

  const onGround = player.body.touching.down || player.body.blocked.down;
  if (cursors.up.isDown && onGround) player.body.setVelocityY(-420);
}

new Phaser.Game(config);

Three things to notice. create runs once to set up the scene, and update runs every frame: that’s the game loop. Gravity and jump speed are plain numbers you can name in prompts (“set jump velocity to -500”). And the onGround check is the classic bug spot: if it’s missing, the player can jump forever in mid-air. Once you know where that line lives, you can describe a bug precisely instead of saying “jumping is broken.”

Common vibe coding mistakes (and the 80/20 fix)

Most failed vibe-coded games fail the same ways:

• Giant first prompts. “Make a roguelike with crafting, multiplayer and a skill tree” gives you a pile of half-working systems. Start with one mechanic.
• Stacking changes without testing. Five requests in a row, then a bug, and you can’t tell which change caused it.
• Pasting errors with no context. Karpathy did it for fun projects. On a real project, add what you were doing: “after collecting the third coin, the game froze and this error appeared.”
• No saved checkpoints. Keep a working copy before risky changes. Version control (Git) is the standard tool, but even a dated copy of the project folder beats nothing.
• Trusting the AI on anything involving user data. Logins, payments and online scores need review, as the Lovable incident showed.

The fix is a version of the 80/20 rule, also called the Pareto principle: roughly 80 percent of results come from 20 percent of the effort. Let the AI do the fast 80 percent, the boilerplate, the menus, the first draft of every system. Spend your own attention on the 20 percent that decides whether the game is good: the controls, the difficulty curve, and any code that touches user data.

The verdict

The Andrej Karpathy vibe coding idea is useful when you take it at the scope he gave it. For jam games, prototypes and personal projects, talking to an AI and steering by results is a quick way to get from idea to something you can play. It gets risky once the project is big, long-lived or handles anyone’s data, which is why even Karpathy moved toward a more supervised framing.

The workflow at a glance:

1. Pick a small, single-mechanic game idea.
2. Vibe code it in an AI game engine such as WizardGenie, one change per prompt, playing after each.
3. Read and understand the core loop once it works.
4. Add real sprites and audio after the mechanics are fun.
5. Review anything that touches accounts, payments or online data, then export your build and host it wherever you like.

Follow the vibes for the fun parts, and stay in control of the parts that can hurt you. That’s how a weekend experiment becomes a game people actually finish.