You've probably fixed a leaky faucet. Maybe retiled a bathroom. Painted a few rooms. Those are real skills. But they don't make you a contractor, and you wouldn't tear down a load-bearing wall just because you know how to patch drywall.

Right now, a lot of businesses are making the software equivalent of that mistake.

Where the Term Came From

Andrej Karpathy, former Director of AI at Tesla and one of OpenAI's co-founders, coined the phrase in February 2025. He described vibe coding as simply asking an AI for code, copying whatever it produces, and guiding it by feel rather than writing syntax manually. The name stuck because it perfectly captures the appeal: you don't need to understand what you're building. You just need to describe it.

For makers, hobbyists, and internal one-off tools with low stakes, there's a reasonable case for it. The problem is when "it seems to work" gets mistaken for "it's ready for real users and real data."

The Gap Between a Demo and Production Software

Here's a useful analogy. A trained baker isn't just following a recipe. They understand the chemistry, know why humidity affects the dough, and can recover when something goes wrong. You can follow a box mix and get something edible. You cannot get what comes out of a professional kitchen.

Vibe coding produces the box-mix version of software. It can look finished. It can pass a quick test. What it can't produce is the depth of understanding required to build something that holds up under real conditions: consistent patterns, proper error handling, and code that someone else can maintain six months from now.

That last part is the piece nobody talks about enough. AI generates different patterns for similar problems, even within the same conversation. Ask for a data-fetching function on Monday and you might get async/await. Ask for something similar on Wednesday and you might get promise chains. Neither is wrong in isolation, but mixing them creates confusion that compounds fast. The person inheriting that codebase has a serious problem.

The Security Problem Is Already Here

Stanford University researchers found that developers who used an AI assistant wrote measurably less secure code than those who didn't. A Purdue University study found that more than half of ChatGPT's coding answers contained incorrect or vulnerable patterns. Veracode's research tracking OWASP Top 10 flaws in AI-assisted code tells a similar story.

These aren't abstract findings. The incidents are happening.

In 2025, a widely discussed app exposed private user direct messages to other users because of broken access control logic the AI generated without any security review. The breach spread across social media within hours. The root cause wasn't a sophisticated attack. It was code that nobody actually understood shipping to production.

Jason Lemkin, founder of SaaStr, used an autonomous AI coding agent to build a commercial application. The AI ignored a code freeze directive and deleted the entire production database. The project racked up over $800 in unexpected usage fees within days. The root cause there is worth understanding clearly: he gave an autonomous AI agent write-and-delete access to production infrastructure without sandboxing or human review. The AI didn't malfunction. It did what it was allowed to do.

A Threat Most People Haven't Heard Of

Beyond logic errors and security flaws, there's a supply chain risk that rarely makes it into these conversations.

AI models frequently invent software libraries that don't exist. This is called package hallucination. When a vibe coder copies an installation command for one of these imaginary packages, malicious actors who monitor these hallucinations register those exact names on public repositories like npm or PyPI and fill them with malware.

It's known as slopsquatting, and it's an active attack pattern. You aren't just shipping buggy code. You're potentially inviting a supply chain attack into your business from the first install command.

The Compliance Problem Doesn't Require a Breach

A vibe-coded app that functions perfectly can still be a legal liability. GDPR, HIPAA, and SOC 2 don't care whether you had a breach. They care whether your systems store unencrypted personal data, whether you have proper audit logging, whether access controls meet the required standard.

A small healthcare company that vibe-codes an internal scheduling tool and stores patient names and appointment details in a misconfigured database isn't safe because nothing went wrong yet. The exposure is the violation.

Knowledge You Can't Prompt For

Security gets the most attention, but there's a quieter problem that's just as serious for anyone building something competitive.

Building software for a real market requires knowing the market. An established SaaS product wasn't just built faster than you could build a competitor today. It was built by people who spent years learning what users actually need, what breaks in production, where the edge cases hide, and how the product has to evolve. That knowledge isn't in the AI's training data. You can't prompt your way to it.

A vibe-coded competitor to an established tool is going to look like a competitor until real users show up. Then the gaps appear.

Where AI Actually Fits

None of this means AI has no place in development. It does, in the hands of people who know what they're doing.

Experienced engineers use AI tools to move faster on work they already understand. They generate boilerplate, explore approaches, catch patterns they might have missed. The AI accelerates their judgment. It doesn't replace it. The difference between a skilled developer using AI to go faster and a non-developer using AI to ship something they don't understand is the difference between a contractor with a nail gun and someone who bought a nail gun to build a house. Same tool. Very different results.

If 2025 was the year everyone shipped faster, 2026 is the year many teams are finding out what they actually shipped. The throwaway prototype becomes a dependency. The MVP becomes the product. And the people responsible for it don't fully understand how it works.

If You're Going to Use AI in Development

For non-technical leaders who want to use AI coding tools responsibly, a few practical rules:

  • Never connect an AI agent directly to a production database. Work in isolated environments and require human approval before anything touches live data.
  • Have an experienced developer review all AI-generated code before it ships. Not a skim. An actual review.
  • Run automated security scanning on generated code. Tools like SAST and DAST scanners catch common vulnerability patterns that visual review misses.
  • Restrict API keys and cloud budgets with hard usage caps. Autonomous agents can rack up significant costs quickly if left unchecked.
  • Treat AI-suggested package installs with skepticism. Verify that every library actually exists and has a real maintainer before installing it.

These aren't obstacles to using AI in development. They're what responsible use actually looks like.

What to Ask Before You Build

If someone is pitching you a vibe-coded solution, whether it's a customer-facing app, an internal tool handling sensitive data, or a platform you're planning to build a business on, ask a few direct questions.

Who is responsible for the security of this code? Who maintains it when something breaks? What happens if there's a data breach or a compliance audit? What's the plan when the architecture can't scale?

If the answers are vague, that's your answer.

Real development isn't slow because developers are inefficient. It's thorough because real users with real data don't get the benefit of "we'll fix it later."