When CodeRabbit went through 470 pull requests, the AI co-authored ones came out with 1.7 times more major issues and 2.74 times the security vulnerability rate of the human-written code. That number, more or less, is where vibe coding sits in 2026. AI writes a big chunk of the new code being shipped, and a lot of it falls over in ways the person who prompted it had no way of anticipating.
If you have ever described an app to an AI and watched working software show up on your screen, congratulations, you have vibe coded. It feels like magic right up until you give the thing to somebody else.
So here we want to walk through what vibe coding actually is, how AI is building software this year, and where it tends to come apart, because we spend a fair amount of our time cleaning up the aftermath. Vibe coding is genuinely useful. It stops being enough the moment your app has users who are not you. If you have already crossed that line and something feels off, the fastest way to know for sure is to have someone look over the AI-generated code who has seen the same failures a hundred times.
What is vibe coding, exactly?
People use the term for anything involving AI and code, which is part of why the arguments about it never go anywhere. Here is what it meant to begin with, and how that has slipped.
Where did the term come from?
Vibe coding means building software by telling an AI what you want and taking whatever it gives you without reading the code. You prompt, the model writes, you run it, and when it breaks you paste the error back and let it have another go. The whole idea is that you never look at how the code works, and you have no intention of looking.
Andrej Karpathy coined it in a February 2025 post. His phrasing, the version everybody quotes, was that you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” What tends to get cut off is the next bit, where he says this is fine for throwaway weekend projects. He was describing a toy, more or less. A fun way to mess around, not a way to run a company.
Fireship’s take is still the clearest short explainer of how the idea spread and why plenty of developers rolled their eyes at it:
None of that tells you anything about whether the result is any good. It only tells you how it was made: you talked, the AI built, and nobody checked the work.
Vibe coding vs AI-assisted coding: what is the difference?
People treat these as the same thing, and that is where the trouble starts, because someone ships a prototype thinking they built a product. The difference comes down to one habit. With vibe coding you do not read the code. With AI-assisted coding you do.
| Vibe coding | AI-assisted coding | |
|---|---|---|
| Who reviews the code | Nobody, or the AI itself | You, or a second AI checking the first |
| Goal | See if an idea works, fast | Build something real and maintainable |
| Attitude to the output | Accept it, move on | Understand it, own it |
| Right for | Prototypes, internal tools, experiments | Products with real users |
Karpathy landed on the same split himself in early 2026. Talking to Sequoia’s Stephanie Zhan at AI Ascent, in a session he titled “From Vibe Coding to Agentic Engineering,” he basically said his own term had aged out for serious work, and that the people doing this properly had moved on to what he calls agentic engineering: still AI agents doing the typing, but with a human checking every step. Worth watching, coming as it does from the guy who named the thing:
So next time someone tells you they vibe coded a feature, worth asking which kind they mean. One is a sketch on a napkin. The other is real engineering that happens to lean on AI.
How does AI actually build software in 2026?
“Vibe coding platform” gets stuck on tools that work nothing alike, and the differences matter a lot more than the landing pages suggest. What changes from one to the next is how much the tool does for you, and how much control you hand over to get it. Every vibe coding AI tool is sitting somewhere on that trade-off.
What are the main types of vibe coding tools?
Broadly speaking, the tools fall into two families.
First, the web app builders: Lovable, Replit, Bolt, v0. You go to a website, describe your app, and the platform sorts out almost everything itself. It rents the server, spins up the AI agent, wires up the backend (the part that stores your data and runs the logic nobody sees), and hands you a working app in the browser inside a few minutes. They come with the plumbing a decent app needs already in place, and they steer you toward sensible defaults, which is the appeal, and also, as we will get to, exactly how they get their hooks into you.
Then there are the developer tools: Cursor, Claude Code, Codex, Antigravity, OpenCode. These sit on your own machine and give you code you can put wherever you want. Cursor is an editor, Claude Code (Anthropic) and Codex (OpenAI) are command-line assistants, Antigravity is Google’s entry, and OpenCode is a free, open-source option you can point at whichever model you prefer. You get far more control this way, and in exchange you do more of the work yourself, from installing what you need to deciding where the finished app is going to live.
The short version:
- Web builders (Lovable, Replit, Bolt, v0) are the vibe coding platforms someone reaches for when they do not think of themselves as a programmer. It is all handled, and you get from idea to live app without opening a terminal once.
- Developer tools (Cursor, Claude Code, Codex) are mostly used by people already doing AI-assisted coding, who want the AI to write code they are still going to read, run, and deploy themselves.
If you never wrote code in your life and your app just worked in a browser, that was almost certainly a web builder. If somebody had to install something first, it was a developer tool.
Who is a vibe coder?
There is no single kind, and treating everyone the same is where most of the bad takes come from. Think of it as a spectrum instead.
- The complete beginner. Watched their first tutorial yesterday, made an account, started clicking screens into being, no clue what is going on underneath.
- The serious learner. Eighteen months of building apps every day with AI, filling the gaps off YouTube and docs as they go. At that point you can call them a programmer and not really be wrong.
- The technical crossover. An ex-WordPress developer, say. Knows what a security hole is, knows a website can be broken into, set the AI agent up carefully before writing a line.
Where somebody sits on that spectrum decides whether their app is anywhere near safe to ship, and it is also why so many non-developers are building software now at all. Roughly 63% of people using these tools are non-developers: product managers, founders, designers. The tools let all of them in. What the tools could not hand out is the years of getting burned that used to come with the territory.
Where does vibe coding break?
AI can write good, secure code. That is worth saying plainly, because the model is usually not the problem. The problem is that whoever is prompting it does not know what to ask for, so the hard parts never get requested. What follows are the failures we see again and again once a vibe-coded app ends up on our desk.
Happy path versus edge cases
A developer with a few years on them is doing two jobs at once without thinking about it. One is building the thing you asked for. The other is quietly handling everything that can go wrong: the empty form someone submits, the ancient browser, the double-click that charges a card twice. That second job is invisible, and it is most of what the experience is actually paying for.
A vibe-coded app only does the first job. You said what should happen, the AI made that happen, and it did nothing beyond that, so it looks perfect on your screen and then buckles the second real people get near it. One user pastes an emoji into a field and the whole page dies. Another uploads a 40-megabyte photo the app was never told to resize. A third opens it on a work laptop where half the buttons land off the edge of the screen. None of it is mysterious, the AI just was never told any of those cases mattered, because the person prompting it did not know they were cases. Someone who has shipped software before would have thought to say “handle the giant file, handle the weird characters, test it on a small screen,” because they have been burned by every one of those, whereas a first-timer has no way of knowing to ask.
Security nobody asked for
Here is the part that makes people wince. AI can do strong security, but only if you ask, and most people building their first app never ask, because it never occurs to them that security is a thing you have to bring up.
The classic disaster is a leaked API key. Your app needs a key to use an AI feature, and that key bills to your account. Put it in the wrong place, publish, and now it is out there for anyone to grab. There are bots doing nothing but scanning for exactly this, and by the time you notice, strangers have been running up your bill for hours. It is common enough that Claude Code now flat-out panics when it spots a key sitting in your history, warns you, tells you to rotate it, though of course you can shrug that off and tell it to just make the thing work.
And it really is that routine. A security audit tied to Lovable (CVE-2025-48757) turned up 170 out of 1,645 apps, north of one in ten, with critical flaws that let one user read another user’s private data. Look at AI-generated code across the board and something like 45% of it carries high-risk vulnerabilities. Once your app is holding personal data, and a plain forum with logins already counts, a leak like that is the kind of thing a product does not come back from. This is where a proper security audit earns its money, and it is a lot cheaper before launch than after the breach.
The data leak you cannot see
The bugs that scare us most are the ones that look completely fine. Picture a tool where different companies each add their own listings. You log in, you see only your listings, so naturally you assume the filtering works. It does not. Under the hood the server is shipping every company’s data down to your browser and the screen is just quietly hiding the rest, which means anyone who cracks open the browser’s built-in dev tools can scroll through everyone else’s records.
To a developer this is obvious on sight, because filtering belongs on the server, where it decides what to send you, not in the browser, which only decides what to show. A non-technical builder is never going to open that hood. They see the right thing on screen and they trust it, and that is precisely the flaw the Lovable audit kept turning up, over and over, in apps built by people who never had reason to learn that the server and the browser are two different places.
The app copies your bad habits
One more thing worth knowing is that AI loves to copy what you have already done, which sounds harmless until you are on a project built without any guardrails.
If you let it skip proper server-side checks for the first couple of weeks, or wave through insecure shortcuts because you want to move fast, it quietly concludes that this is simply how the project is done and starts repeating the pattern everywhere, so every new feature inherits the same mess as the last one.
That is the real reason to get a second opinion early, in the first few weeks rather than six months in. Set decent patterns at the start and the AI keeps to them; set sloppy ones and it will faithfully reproduce them in corners of the app you never even asked it to touch.
Why does platform lock-in matter?
Say the code were flawless. You could still end up stuck, because on some platforms the risk has nothing to do with code quality and everything to do with the business underneath it.
What does lock-in look like?
Lock-in is an old trick: make leaving hurt. Once your app is living on a platform and doing well, the platform has every reason to make moving somewhere else expensive, and not much reason to keep staying cheap.
Here is how it tends to go. You pay some modest monthly fee, you build a pile of apps nobody uses. Then one of them takes off, pulls real traffic, starts loading their servers, and now the leverage is all on their side. They can raise your price specifically, and the “unlimited” in the fine print turns out to have a ceiling after all. The whole time they are doing one calculation: how much can we charge this person before rewriting from scratch starts to look cheaper than staying.
The thing that really catches people out is what you can take with you when you go. One founder we worked with built on a hosted builder, got real traction, went to export the app, and found he could pull the front end but not the back end. The platform’s agent had written the entire backend and it simply would not come out. He came to us to have the whole thing rebuilt from zero, because there was no other way off.
So if you are building on one of these, ask the boring question before you commit: what exactly can I take with me, and can I run it somewhere else.
When does lock-in actually matter?
None of this makes the platforms something to avoid on principle. You just size the risk against what is at stake.
Vibe code an app for your grandmother, or a scorekeeper for the five-a-side you play on Thursdays, and lock-in genuinely does not matter, use whatever is easiest. But if the plan is three years and real money into marketing this thing, a platform that can take your backend hostage the day you finally succeed is a business risk you can feel. It scales with how much you are putting in, which is the whole point.
When is vibe coding enough, and when should you call a software house?
None of this is us telling you not to vibe code. It is us saying the method has to match the stakes, and most of the arguing about it evaporates the second you are honest about what you are building.
When are the vibes fine?
For plenty of projects, hiring anyone would be money down the drain. If you can build it yourself and it does the job, build it yourself. The easy cases:
- Apps only you will ever touch, on your own machine, where a bug costs you nothing but a shrug.
- Internal tools for a small team that can live with the odd glitch.
- Proofs of concept, where the entire point is finding out whether an idea has legs before you spend on it.
- Idea validation, trying something on a few friends before real money is involved.
Karpathy’s original throwaway framing fits every one of these, since it was always meant for the rapid and disposable end of things. The mistake only shows up when someone takes that same disposable thing and aims it at paying customers.
When do you need real oversight?
The second your app has real users, or touches personal, financial, or health data, or is something you actually plan to sell or scale, the maths changes, and a review and cleanup of the code turns into about the cheapest insurance you can buy. The way we usually run it is three steps:
- Consultation – a short chat, sometimes free, where an experienced developer looks at what you have and tells you straight whether it is fine as-is, needs a couple of fixes, or wants a full audit. Sometimes the honest answer is “leave it, it works,” and a partner worth their salt will tell you that instead of selling you something.
- Audit – actual checks against your actual code: does it hold up under real traffic, is the data locked down, where can it leak. An app knocked together over a week or two, that might be a few hours. A sprawling six-month thing with millions of lines nobody fully remembers writing, that can take a good while longer.
- Fix or rewrite – depending on what the audit turns up, we either patch what is there or rebuild the parts that are past saving, sometimes on the same tech, sometimes moving it onto something we know inside out.
If there is one thing to take away, it is this: the longer you build without really knowing what you are building, the better the odds you end up binning it. Getting someone to look while the app is still small is almost always cheaper than untangling it later. And if your project has already grown past the point where you are confident it is sound, that is your cue to have it looked at before you scale.
FAQ about vibe coding
What is vibe coding actually?
Vibe coding is building software by describing what you want to an AI and taking the code it gives you without reviewing it. You prompt in plain language, run whatever comes out, and paste errors back for the AI to fix. The defining bit is that you do not read or try to understand the underlying code. Andrej Karpathy coined the term in February 2025 for exactly this hands-off, experimental way of working.
Why did vibe coding fail?
It did not really fail, it got misused. As a way to prototype and experiment it works great, and it is more popular now than ever. The problems start when someone takes a vibe-coded app, which by definition nobody reviewed, and pushes it live to real users. That is when the missing edge cases, the absent security, and the hidden data leaks all show up at once. Even Karpathy has moved on from the term for serious work, in favour of the more careful, review-heavy approach he calls agentic engineering.
Is vibe coding a real job now?
Sort of, though nobody’s job title is “vibe coder.” The paid work forming around AI-generated code looks more like this:
- Reviewing and hardening apps that got built fast and now have to be safe for production.
- Auditing codebases for the security holes and data leaks the original builder could not see.
- Product and system design, which got more valuable precisely because writing code got cheap.
The common thread: writing code is not the scarce skill anymore. Judging it, securing it, and deciding what to build are.
How legit is vibe coding?
Very legit as a technique, with real limits. Y Combinator said 25% of its Winter 2025 startups were running on codebases that were 95% AI-generated, and those were funded companies shipping to real users, not weekend hobbyists. The question was never whether AI can build software, it plainly can. The question is whether a given app got the review, security, and testing that production demands, or whether it only got the vibes.
Is vibe coding safe for production apps?
On its own, no. A vibe-coded app can absolutely become production-ready, just not while it is still only vibe-coded:
- The good news: a vibe coding AI can write secure, well-tested, production-grade code when it is told to.
- The catch: it has to be told, and non-technical builders rarely know what to ask for.
- The fix: an audit before launch covering security, data access, traffic load, and the edge cases the first build skipped.
For anything with real users or sensitive data, treat the working prototype as a starting point and get it reviewed and hardened before it goes live.
