Vibe coding: prompting your way to a working app

Andrej Karpathy gave it a name in early 2025, and the name stuck. Vibe coding is what it sounds like. You describe what you want, the model writes it, you run it, something breaks or surprises you, you describe what to fix, and you keep going. You aren't reading every line. You're driving the feel of the thing.

It works better than it should. It also fails in very specific ways. Knowing both is the whole skill.

The actual loop

Real vibe coding is four steps in a tight cycle.

Describe what you want. Generate it. Run it. Refine.

The mistake people make is expecting the first prompt to land. It almost never does. Vibe coding is not one perfect prompt, it's a conversation where each round adds context the model didn't have before.

Here's what that looks like for "build me a CRUD form for tracking books I want to read."

Prompt 1, the opener, into Lovable or Bolt:

Build a small web app where I can add books to a "want to read" list.
Each book has: title, author, why I want to read it, date added.
I want to mark a book as "started" or "finished" later.
Single page, no login, store in local storage for now.

You'll get something. It will look fine. You'll click around and notice the "started" toggle doesn't persist on refresh, or the date format is American when you wanted ISO, or the textarea for "why" is one line tall.

Prompt 2 is the patch:

Two things. The "started" status doesn't survive a page refresh, fix the
local storage write. And make the "why" field a textarea, 4 rows, not a
single-line input.

Prompt 3 is when you start asking for things you didn't think of upfront. Sort by date added. Filter by status. Maybe a count at the top. Prompt 4 is the polish round, a cleaner empty state, a confirmation before delete.

Four prompts, twenty minutes, working internal tool. That's the shape.

Where it actually shines

Vibe coding earns its keep on disposable code.

Throwaway scripts that rename 400 files. Internal dashboards three people will use. Glue between two APIs you'd otherwise wire up by hand. Prototypes you'll show to five users on Friday and rewrite or kill on Monday. The "is this idea even worth building" experiments where the answer is usually no, and you needed a working thing in front of someone to find that out.

The common thread: the cost of a bug is low, the cost of your time is high, and nobody is going to maintain this in two years.

Where it falls apart

It breaks the moment any of these enter the picture.

Complex state. Anything with multi-user editing, real-time sync, or a state machine with more than three branches. The model will write something that looks right and behaves wrong on the fifth interaction.

Performance. If it has to handle 100k rows, run on a phone, or render under 16ms, the model's default code is not going to clear the bar. It writes the average solution.

Security boundaries. Anything that touches auth, payments, PII, or your database from the client. The model will happily expose an API key in frontend code if you don't catch it.

Long-term maintainability. Vibe-coded code is often correct and unreadable. Six months later you can't remember why a function is shaped that way, and neither can the model, because you're in a fresh context.

Niche or new libraries. The model's training data on a library that shipped four months ago is thin. It will confidently call methods that don't exist. This is also true for internal frameworks at your company.

The rule is simple. If a human would need to understand this code later, you can't fully vibe code it. You can start with vibe coding, but at some point you have to read what's there.

What to use it on, this week

Pick something boring you've been putting off. A form that emails you when someone fills it out. A scraper for a site you check every morning. A small UI for a CSV your team keeps editing in five different copies. Open Lovable or Bolt for the standalone web thing, v0 if you want React components you'll paste into an existing app, Cursor or Claude Code if it lives in a real codebase you already maintain.

Time-box it. Thirty minutes. If you don't have something working at thirty minutes, the prompt is wrong or the task isn't a vibe coding task.

Next up

Each of those tools has a different sweet spot, and picking the wrong one wastes a weekend. The next guide breaks them down side by side: Pick your build environment, Lovable vs Bolt vs Cursor vs Claude Code.