Vibe Coding in 2026: What It's Good For, and When You Need a Real Developer

"Vibe coding" is the term for building software by describing what you want to an AI tool and accepting what it generates, rather than writing or closely reviewing the code yourself. Andrej Karpathy — an OpenAI co-founder and former Tesla AI lead — coined it in a February 2025 post on X, describing a state where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Eighteen months later, it's not a niche habit. It's a $4.7 billion-a-year market, the thing behind an 84% surge in Apple App Store submissions, and — per Upwork's own 2026 data — a big part of why demand for AI-related freelance skills has more than doubled.

It's also, verifiably, why a Supabase database with 1.5 million exposed API tokens got found by security researchers three days after launch, and why a well-funded vibe-coding platform spent 48 days quietly leaking other users' source code before anyone fixed it. Both things are true at once: vibe coding is genuinely good at some things, and it has a real, documented, growing failure record at others. This post is about telling those apart — grounded in our own Build a Web App with AI cost data, plus independently re-verified 2026 research on where vibe coding breaks.

The useful distinction isn't "using AI to code" versus "not using AI to code" — plenty of professional developers do the former without it being vibe coding. Karpathy's original definition is about not reviewing the output: you describe the feature, the AI writes it, and you move on based on whether it looks like it works, not because you checked how it works. That's the difference between a developer using Cursor's autocomplete to move faster, and a founder telling Lovable "add user accounts and a payments page" and shipping whatever comes back.

Two things have changed since Karpathy's original post. First, the audience: an estimated 63% of vibe coding users today are non-developers — people who couldn't write the code themselves even if they wanted to review it. Second, ironically, Karpathy himself moved on. In early 2026 he called vibe coding "passé" and started pushing a new term, "agentic engineering" — orchestrating AI agents with actual engineering discipline (specs, tests, review) rather than just vibing. The term he coined turned into the cautionary tale his own follow-up was reacting to.

"Vibe coding tool" covers a spread from fully no-code chat builders to AI-native code editors that still assume you can read what they write. Our own Build a Web App with AI task guide tracks the stack most people actually use, start to finish:

None of this is a case against vibe coding categorically — for the right project, it's a legitimately good trade. Four situations where it holds up well:

• Validating an idea before you spend real money. A rough, working prototype that proves (or kills) a business idea in a weekend beats a $3,000 developer quote for something you might scrap in a week.
• Internal tools with a known, small audience. A dashboard your own team uses, with data you already control, has a fundamentally smaller blast radius than something public strangers sign up for.
• Personal projects with no other users. If the worst case is you personally losing your own data, the stakes are genuinely different from a multi-tenant app holding other people's information.
• MVPs, explicitly framed as disposable. If you go in planning to rebuild the real version once the idea is validated — the way Bolt.new is widely used — vibe coding is doing exactly the job it's good at.

Our own numbers back this up on the cost side: building a web app with AI runs a realistic $25-$80/mo in tools against a $500 freelance-hire floor — a +$448 cost gap, the widest of any of the 12 tasks we track. That's real money on the table for the right project. The catch, which our own data flags directly, is that it's also the only task in that 12-task set rated "hard" difficulty — and the one whose finishing checklist reads like a security audit, not a polish pass.

This isn't a hypothetical "AI code can have bugs" warning — 2026 has produced hard research and two named, independently-reported incidents. We re-verified all of the following directly rather than taking any single source's word for it:

Notice what both incidents have in common: neither was a sophisticated attack. Moltbook and Lovable were both broken by the same unglamorous thing — access control that a human reviewer would have caught in minutes, and that AI-generated scaffolding doesn't reliably add on its own. That's exactly the risk our own Build a Web App with AI task guide already names in its humanShouldFinish field: "Row-Level Security rules... a 200 ≠ a session." It's not an abstract warning. It's the specific thing that took down two real, funded products in 2026.

There's a second, quieter failure pattern worth naming: slopsquatting. LLMs occasionally invent package names that don't exist, and attackers have started pre-registering those exact names as real (malicious) packages — so a future hallucination silently pulls in someone else's code. It's a supply-chain risk unique to how these tools generate code, not a traditional bug.

Both incidents above share a shape that's become common enough in 2026 that it has an informal name in vibe-coding trade blogs — the "90-day reckoning": the point where a project that shipped fast on vibes hits its first real maintenance moment, and a function nobody fully understood a month ago is now the thing blocking a fix. We'd caution against treating the specific dollar figures floating around for that phrase as verified — several sites cite near-identical numbers without a named, checkable source, which is its own small case study in how fast unverified stats spread in this space. The underlying mechanism, though, is backed by real data: LinearB's 8.1M-PR study above, plus a simple truth about how these tools work — they optimize for "looks like it's working right now," not for what happens when your tenth, hundredth, or ten-thousandth real user hits an edge case the demo never covered.

Concretely, that means: database queries that are fine at 10 test rows and fall over at 10,000 real ones; auth checks that work for the one test account but not for a second real user; and — as both Moltbook and Lovable showed — access-control gaps that don't matter until a stranger has a reason to go looking for them.

The honest answer isn't a fixed rule — it's a moving line that shifts as three things grow: how many real people use your app, how sensitive what they give it is, and whether anyone has actually reviewed what the AI wrote. Answer these four questions honestly: