Vibe Coding Is Real — But Here's What Non-Developers Get Wrong About It

Andrej Karpathy coined "vibe coding" in early 2025 and the term stuck because it described something real. You describe what you want in plain English, an AI writes the code, you run it, and if something breaks you paste the error back and let the AI fix it. No reading documentation. No understanding the code. Just vibes.

And honestly? For certain things, it works shockingly well.

The problem is that "works shockingly well for demos" and "works in production" are separated by a chasm that most people don't see until they're falling into it.

What Vibe Coding Is Good At

I'm not here to trash AI coding tools. I use them daily. Claude, Cursor, Copilot — they're part of my workflow now and I'm more productive because of them. Here's where they genuinely shine.

Prototyping and MVPs

Need a working prototype to validate an idea? AI tools can get you from zero to a functional demo in hours instead of days. Landing pages, simple dashboards, CRUD apps — the AI handles 80% of the work and you polish the rest.

For a founder testing whether an idea has legs, this is transformative. You can build and test three concepts in the time it used to take to spec out one.

UI Generation

This is arguably where AI coding is most impressive. Describe a component — "a pricing card with three tiers, toggle between monthly and annual, dark theme" — and you get working React/Vue/Svelte code that looks decent. Tailwind CSS generation in particular is almost eerily good.

Boilerplate and Glue Code

Setting up a Next.js project with auth, database connection, API routes, and deployment config? The AI knows the patterns cold because it's seen thousands of identical setups. This is the programming equivalent of filling out forms — necessary but not creative — and AI handles it well.

Simple Automation Scripts

"Write a Python script that reads a CSV, filters rows where the date is older than 30 days, and sends a summary email." This is a perfect vibe-coding task. Clear inputs, clear outputs, limited complexity. Ship it.

The Production Cliff

Here's where the narrative falls apart. I've been called in to rescue multiple projects that were "90% done" with vibe coding. In every case, the last 10% represented 90% of the actual engineering challenge.

Security Is an Afterthought

A 2025 Stanford study found that developers using AI assistants produced code with 45% more security vulnerabilities than those coding manually. That number hasn't improved much because the root cause isn't the AI — it's that security requirements are rarely stated explicitly, and AI optimizes for "make it work," not "make it safe."

Real examples I've seen in vibe-coded projects:

• API keys hardcoded in frontend JavaScript, visible to anyone who opens DevTools
• SQL queries built with string concatenation instead of parameterized queries
• Authentication tokens stored in localStorage with no expiry
• File upload endpoints with no validation — upload a PHP shell, get a webshell
• CORS set to * because the AI was fixing a CORS error and took the path of least resistance

None of these show up in a demo. All of them are catastrophic in production.

State Management Disasters

AI is great at building individual features. It's terrible at managing how features interact with each other. The shopping cart works. The user profile works. But add an item to the cart, change your shipping address, and apply a discount code simultaneously? The app breaks in ways that are nearly impossible to debug because the state management is a patchwork of quick fixes.

This is because AI generates code one prompt at a time. It doesn't hold a mental model of the entire system's state flow. Each response optimizes locally, not globally.

The "It Works" Trap

When a non-developer says "it works," they mean: "I clicked the buttons and the right things appeared on screen." When an engineer says "it works," they mean something very different:

• It works under load (100 concurrent users, not just 1)
• It works with bad input (empty fields, SQL injection attempts, 50MB file uploads)
• It works when external services fail (API timeout, database connection dropped)
• It works tomorrow (dependencies are pinned, migrations are reversible)
• It works for debugging (logs exist, errors are caught, state is observable)

Vibe-coded projects almost never have error boundaries, retry logic, input validation, rate limiting, or structured logging. The happy path works. Everything else is undefined behavior.

No Error Handling

This is the single most common issue. I opened a vibe-coded Next.js project last month and searched for try/catch blocks. Found three — in a codebase with 47 API routes. Every database query, every external API call, every file system operation was naked. One network hiccup and the whole app crashes with an unhandled promise rejection.

// What the AI generated
const data = await fetch('/api/orders').then(r => r.json());
setOrders(data);

// What production code needs
try {
  const response = await fetch('/api/orders');
  if (!response.ok) {
    throw new Error(`Orders API returned ${response.status}`);
  }
  const data = await response.json();
  setOrders(data);
} catch (error) {
  logger.error('Failed to fetch orders', { error });
  setError('Unable to load orders. Please try again.');
  // Maybe trigger a retry with exponential backoff
}

The first version works in development, on localhost, with a fast connection. The second version works in the real world.

The Maintenance Trap

Here's the thing nobody talks about: vibe-coded projects are nearly impossible to maintain.

When nobody on the team actually wrote or understands the code, every bug becomes a guessing game. You can't reason about code you didn't write and don't understand. You paste the error into the AI, it suggests a fix, you apply it, and now you have two problems — the original bug and whatever side effects the fix introduced.

I've watched this cycle play out over weeks. Each AI-generated fix creates new edge cases. The codebase accumulates layer after layer of patches. Eventually the whole thing needs to be rewritten from scratch, because the technical debt isn't in any one place — it's structural.

This is the cruel irony of vibe coding: the faster you build, the faster you might need to rebuild.

When Vibe Coding Is the Right Call

I'm not arguing against using AI to write code. I'm arguing against using AI instead of understanding code. There's a huge difference.

Use vibe coding for:

• Internal tools that five people will use and nobody will attack
• Prototypes you'll throw away after validation
• One-off scripts and data transformations
• Learning new frameworks (generate code, then study what it did and why)
• Hackathon projects and proof-of-concepts
• Static marketing sites with no user data

These are all cases where the cost of failure is low and speed matters more than robustness.

When You Need a Developer

Hire an engineer when:

• The app handles user data (PII, payment info, health records)
• You're processing payments or financial transactions
• You need integrations with third-party APIs (auth flows, webhooks, error handling)
• The app needs to scale beyond a handful of users
• You're in a regulated industry (healthcare, finance, legal)
• The project needs to be maintained for more than six months
• Security matters (which is almost always)

The value of an experienced developer isn't typing code faster. It's knowing what not to build, how systems fail, and where to invest in resilience. An AI doesn't know that your webhook handler needs idempotency keys. It doesn't know that your background job processor needs dead letter queues. It doesn't know that your database queries need indexes on the columns you're filtering by.

These aren't obscure edge cases. They're table stakes for production software.

How I Actually Use AI Coding Tools

My workflow looks nothing like the vibe-coding demos on Twitter. I use AI tools extensively, but I'm driving.

Architecture is mine. I decide the system design, data models, API contracts, and deployment topology. AI doesn't make architectural decisions.

AI writes first drafts. I describe a function or component, the AI generates it, and I review it line by line. I know what I'm looking for — error handling, edge cases, security implications, performance characteristics.

AI accelerates, it doesn't replace. I use it to write tests, generate boilerplate, refactor existing code, and explore unfamiliar APIs. It saves me time on the mechanical parts of programming so I can focus on the decisions that actually matter.

I always read what it generates. Every line. If I can't explain why a piece of code works the way it does, I don't ship it. This is the fundamental rule that separates productive AI-assisted development from vibe coding.

Vibe coding:  "AI, build me a login system" → ship it
AI-assisted:  "AI, build me a login system" → review → fix auth flow → add rate limiting → add session management → ship it

The output might look similar. The reliability is worlds apart.

The Real Opportunity

The developers who are thriving right now aren't the ones ignoring AI tools, and they're not the ones blindly trusting them. They're the ones who use AI to eliminate the boring parts of programming while applying their expertise to the parts that matter.

If you're a non-technical founder, the takeaway isn't "AI can replace developers." It's "AI makes good developers faster and more affordable." The cost of building software is dropping. The cost of building reliable software hasn't changed nearly as much, because reliability comes from experience and judgment, not from generating more code faster.

The best investment isn't a better AI coding tool. It's pairing AI tools with someone who knows what production software actually requires.

If you're building something that needs to work beyond a demo — something that handles real users, real data, and real money — let's talk. I use AI tools to build faster, but I bring the architecture and engineering judgment that keeps things running.