vibebuilt
/ Vibe Coding / What Is Vibe Coding? A Builder's Honest Answer
Vibe Coding 13 min read

What Is Vibe Coding? A Builder's Honest Answer

What is vibe coding, honestly? A builder who ships real products with Cursor and Claude Code on where the AI wins, where it breaks things, and who it's for.

What vibe coding actually is, a builder's honest answer

Vibe coding is letting an AI write your code from plain-English prompts while you steer by feel instead of reading every line. That's the honest one-sentence answer to what is vibe coding, and it's close to how Andrej Karpathy meant it when he coined the phrase in early 2025. You describe what you want, the agent types it, and you mostly react to whether the thing runs.

I do a version of this every week. I use agentic tools like Cursor and Claude Code to design, build, and actually ship real public products, not localhost demos that die in a screenshot. So here's the part the definition pages skip. Vibe coding is genuinely powerful and genuinely oversold at the same time, and the gap between those two things is the whole story.

The agent does the typing. What it doesn't do is decide anything that matters. Once you sit with that one line, vibe coding turns from a magic trick into a normal tool, and you stop waiting for the prompt that builds the finished app for you. That prompt isn't coming. If it were, the people selling it would just ship the apps themselves and skip charging you a subscription.

Where The Term Actually Came From

The phrase has a birthday. Andrej Karpathy, who helped start OpenAI and used to run AI at Tesla, posted it in February 2025. His line was that there's a new kind of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Forget that the code exists. That's the actual origin, and it matters, because a lot of what gets called vibe coding today isn't that at all.

Simon Willison, a programmer who writes clearly about this stuff, drew a line the vendor pages tend to blur. If an LLM wrote every line of your code, but you reviewed it, tested it, and understood it, that's not vibe coding. That's using an AI as a fast typist. Real vibe coding, the pure form, is the part where you don't look. You accept the diff, you run the app, and you judge it by whether it worked, not by whether the code underneath is any good.

The term stuck fast, weirdly fast. Merriam-Webster tagged it as slang and trending by March 2025, and Collins English Dictionary named it their Word of the Year for 2025. A year before that it didn't exist. Now it's in the dictionary and on a hundred landing pages, which tells you something about how quickly this corner of software moved.

What Vibe Coding Really Looks Like When You Ship

Here is my actual loop, minus the romance.

I open Cursor or Claude Code, describe the feature I want in normal sentences, and let the agent write the first draft of it. For a new screen on Apatero, my AI creative studio, that might be a whole component, the API call behind it, and the styling, roughed in during the time it would take me to find the right file by hand. Then I read it. Not every line, honestly, but the parts that touch money, auth, or user data, always. I run it. I see what broke. I tell the agent what broke, or I just fix it myself when that's faster than explaining.

That's the shape of it. The agent is doing eighty, ninety percent of the keystrokes and close to none of the deciding. What to build, whether the result is any good, when it's done, when the agent has quietly wandered off into confident nonsense, all of that stays with me. I've shipped Tool Index, a directory of software tools, and I keep my own site kevingabeci.com running this way, plus a couple of small games and music tools on the side. None of them wrote themselves. They got typed by an agent and shipped by a person.

One thing that quietly changed how loosely I work is cost. A lot of the generation my products lean on, the images and the audio, runs locally on an M4 Pro, so the marginal price of throwing a bad idea at it and deleting the result is close to nothing. That instinct carries straight into the coding. When regenerating a broken attempt is basically free, you stop being precious about the agent's first draft. You let it try, and when it misses you discard the whole thing and go again, and that willingness to throw work away is a bigger part of vibe coding than any single clever prompt.

If you want the specific tools I reach for and why, I broke that down in the best AI coding tools. And since everyone eventually asks which of the two big agentic editors is better, I put them head to head in Cursor vs Claude Code.

The Difference Between Shipping and a Demo

Most vibe coding content stops at the moment the app runs on your laptop. That's the exact moment the hard part starts.

A demo is a thing that works once, on your machine, with you being gentle to it. A shipped product is a thing a stranger can open, misuse, break, and come back to, that stays up while you're asleep. The agent is fantastic at the first one and not much help with the second. It'll get you a login page that looks great and a database that works in the happy path. It will not, on its own, handle the person who signs up with an email that already exists, or the payment webhook that fires twice, or the mobile browser that renders your layout sideways.

I want to say the last ten percent is where the real work lives, but honestly it's closer to the last half. Auth edge cases. Error states. The empty-state screen nobody bothers to prototype. Rate limits, and the one bug that only shows up in production at 2am. That's the actual job, and vibe coding gets you to the demo fast and then goes quiet right when the shipping starts. I wrote a longer piece on crossing that exact gap for a real app in how to build a SaaS with AI, because the demo-to-shipped stretch is where most vibe-coded projects quietly die.

What The Agent Genuinely Nails

Credit where it's earned, because "AI can't really code" is as wrong as "AI writes the whole app."

Boilerplate is the obvious one. CRUD endpoints, form validation, a config file, the fortieth React component that looks like the other thirty-nine. This stuff is nearly identical across every project on earth, and the agent writes it fast and mostly right. Translating between languages, too. Hand it a Python function, ask for the TypeScript version, and it'll get there more often than not.

It's a strong rubber duck. When I'm stuck, describing the bug out loud to the agent sometimes surfaces the answer before it even replies, and when it does reply it's occasionally right in a way that saves an hour. It handles the tedious refactor, the rename-across-forty-files job, the regex I can never remember. And it's a genuinely good explainer of code I didn't write, which matters more than people admit the day you inherit somebody else's mess.

There's a whole category of these agentic tools now, and they differ a lot in how much rope they hand you. I sorted through which ones actually earn their keep over in AI coding agents.

Where It Confidently Breaks Things

Now the part the landing pages leave out, because bugs don't sell subscriptions.

The agent hallucinates code. It will call a method that does not exist, with total confidence, formatted perfectly, and you only find out that function was never real when you run it. It'll import a package you don't have installed. It'll invent a config option that sounds plausible and isn't. I once watched an agent suggest the same broken fix four times in a row, cheerful every time, like a GPS that keeps routing me into the same lake, and I kept saying no and it kept saying sure, try this, and offering the lake again.

The quiet failures are worse than the loud ones. You ask for a new feature and it silently rewrites a working function nearby, and now something that ran fine yesterday is broken and you don't notice for a day. The flat confidence is what gets you. A junior developer at least sounds unsure when they're guessing, and the agent never sounds unsure about anything, so you start trusting the tone and stop checking the substance. That's how a made-up method ends up in a commit.

Here's the split as I've actually lived it, across a real build. Left column is what I let the agent run with. Right column is what I had to take back by hand.

Build Stage What The Agent Nailed What I Fixed By Hand
Scaffolding a feature Files, imports, the boring wiring Whether the feature was worth building at all
First-pass code Working happy-path logic, fast The edge cases it never thought about
Styling A clean, decent-looking first draft Mobile, dark mode, the real brand feel
API integration Calling a well-documented endpoint The auth flow and retry-on-failure logic
Debugging Reading a stack trace, guessing a cause The bug that only existed from my weird wiring
Refactoring Mechanical renames across many files Deciding what the structure should be
Making it production-ready Almost nothing, honestly Basically all of it

Look at that bottom row. The closer you get to shipping, the less the agent helps, and shipping is the part that actually decides whether you built anything.

So Is Vibe Coding Bad?

Short answer, no, but it has a real dark side and the criticism isn't only gatekeeping.

The security record is genuinely rough when nobody's reviewing the output. One vibe coding platform, Lovable, shipped a batch of apps in 2025 where 170 out of 1,645 of them exposed users' personal data, per the reporting collected on Wikipedia's page for the term. A Veracode study around October 2025 found AI-generated code kept getting more functional while its security barely improved. And a CodeRabbit analysis late in the year found AI co-authored code carried something like 1.7 times more major issues and nearly 2.7 times the security vulnerabilities of human-written code. I'd want to read each study's methods before I treated the exact figures as gospel, but the direction is consistent, and it lines up with what I see. Code that nobody reads is code where nobody caught the holes.

So the honest version of "is vibe coding bad" comes down to stakes. Pure vibe coding, the accept-everything-and-don't-look kind, is fine for a throwaway toy and a poor idea for anything holding real user data. The moment there's a login or a payment involved, you're back to reading the code, and at that point you're not really vibe coding anymore by Willison's definition. You're just coding faster with good help.

Straight Answers to the Rest of the Questions

The search results throw the same handful of questions at you, so here are plain answers.

How does vibe coding actually work? You pick a tool that speaks your stack, describe what you want in normal language, look at what it generates, and nudge it until the thing runs. Then you test it, or you skip testing and hope, which is the part that separates a weekend hobby from something you'd let a stranger touch. The loop is prompt, generate, run, react, and go again.

What's an example of vibe coding? Say you want a little dashboard that shows your website's traffic. You tell the agent "build me a page that pulls my analytics and charts the last 30 days," it writes the fetch, the chart, and the layout, and ninety seconds later something renders on screen. You didn't write a line. You described a vibe and got a page back. For a personal dashboard that's honestly great. Point the same approach at a real product with real users and it gets a lot riskier.

Is vibe coding just coding with AI? Not quite, and this is where people talk past each other. Using AI to help you code, while you review and understand everything it writes, is just coding with AI. Vibe coding is the stricter thing where you stop reading and trust the output. Most people who say they vibe code are actually doing the reviewed version, which is the safer and more honest way to work anyway.

What's the difference between vibe coding and prompt engineering? Prompt engineering is crafting the input to squeeze a better answer out of a model. Vibe coding is a way of building software that happens to lean on those prompts. One is a technique you can use anywhere. The other is a whole way of working. You use prompt engineering inside vibe coding, not instead of it.

Why is it even called vibe coding? Because Karpathy said you "give in to the vibes" and stop caring about the code itself. The name is doing exactly what it says on the label. You steer by feel, by whether the app gives off the right vibe when you run it, rather than by reading the logic underneath. It's a strangely honest name for the practice.

Is vibe coding the future? Some of it, sure. The typing-assistant half is already just how a lot of us work now, me very much included. The don't-look-at-the-code half I'm less sure about, at least for anything serious, because somebody always ends up having to read the code when it breaks, and it always breaks eventually. Where the line finally settles five years out, I genuinely don't know. Nobody does, whatever they're selling you.

Who Vibe Coding Actually Works For

So who should actually do this.

If you're a non-coder who wants a personal tool, a scrappy prototype, a thing only you'll ever use, vibe coding is the best gift you've been handed in years. Go wild with it. Accept the code, don't look, ship it to yourself. The stakes are zero and the payoff is a working thing that didn't exist this morning.

If you're a developer, it's a real speed multiplier as long as you keep a hand on the wheel. Let the agent type, keep doing the judging, read the parts that matter. You'll move faster than you did last year and you'll catch most of the confident nonsense before it ships. That's basically the working setup for people like me who use these tools all day.

And if you're building something with other people's data, money, or trust riding on it, pure vibe coding is the wrong tool, and a good share of the horror stories come from ignoring that. Use the agent, absolutely. Just read the code. The version of me that ships real products isn't fighting the AI and isn't worshipping it either. I let it do the typing, I make the calls, and I own whatever ends up going out the door. That's the whole practice, and no prompt is going to take that last part off your hands.