Vibe Coding: Where It Works, Where It Doesn't, and How Not to Wreck Your Codebase

A founder showed me their new product last month. Built it in a weekend with Cursor, barely wrote a line of code himself. "Vibe coding," he said. And honestly? The demo was impressive. Clean UI, working auth, Stripe integration, the whole thing.

Then I looked at the codebase. No tests. SQL injection vulnerabilities in every form. API keys hardcoded in the frontend. A single 2,000-line component doing everything. It "worked" — the same way a car with no seatbelts and no brakes "works" until you need to stop quickly.

Vibe coding is real. It works. And it's going to cause a wave of production incidents for companies that don't understand its limitations.

Where Vibe Coding Actually Works

Prototypes and proof-of-concepts. This is the killer use case. You have an idea, you describe it, and you have a working demo in hours instead of weeks. For validating a concept with customers or stakeholders, this is genuinely transformational. The code doesn't need to be production-quality because it's never going to production.

Internal tools and scripts. Need a script to parse a CSV and load it into a database? A quick admin dashboard for an internal process? A data transformation pipeline that runs once? Vibe code it. The quality bar is lower, the audience is internal, and the cost of bugs is manageable.

Learning and exploration. Working with a new framework or language? Describing what you want and reading the generated code is an incredibly efficient way to learn patterns. It's like pair programming with someone who knows every API but has no judgment about architecture.

First drafts. Even for production code, vibe coding can generate a useful starting point that an experienced engineer then refactors, tests, and hardens. Think of it as scaffolding, not as the finished building.

Where It Falls Apart

Security. AI models generate code that works, not code that's secure. They'll use patterns they've seen frequently in training data — including insecure patterns from tutorial code, Stack Overflow answers, and repositories that never worried about security. Authentication, authorization, input validation, secrets management — these require deliberate security thinking that current AI models don't reliably provide.

Performance at scale. Vibe-coded applications work fine with 10 users. At 10,000 users, the N+1 queries, missing indexes, unoptimized algorithms, and memory leaks reveal themselves. AI models optimize for correctness, not for performance under load.

Maintainability. Code that nobody understands is code that nobody can debug. If a vibe-coded feature breaks at 2am and the engineer on call didn't write it and can't read it, your mean time to recovery just tripled. Every line of code in production should be understood by at least one person on the team.

Compliance-sensitive domains. Healthcare (HIPAA), finance (PCI DSS), education (FERPA) — these environments have specific coding requirements around data handling, audit logging, and access controls. AI models don't know your compliance requirements and will happily generate code that violates them.

The Pragmatic Approach

Vibe coding isn't all or nothing. Here's how I advise teams to use it:

Phase 1: Generate. Use AI to produce a first draft. Describe what you want. Let it build the scaffolding, the UI structure, the basic logic flow.

Phase 2: Review. Treat the output like a PR from a talented but inexperienced developer. Review every line. Understand every decision. Question every pattern. If you can't explain why the code works, you can't fix it when it doesn't.

Phase 3: Harden. Add tests. Fix security issues. Handle edge cases. Optimize queries. Add error handling. This is the engineering work that turns a demo into a product.

Phase 4: Own. Once the code passes review and testing, it's your code. The AI generated it, but you're responsible for it. It goes into your repository, your CI/CD pipeline, your monitoring.

The Organizational Risk

The bigger danger isn't individual code quality — it's organizational. When AI can generate code faster than teams can review it, the pressure is to skip the review. "It works, ship it." This creates a codebase that works today and becomes unmaintainable in six months.

Set clear policies: AI-generated code follows the same review standards as human-written code. No exceptions. The speed gain from AI should be in generation, not in skipping quality gates.

And watch for the skills gap. If junior engineers learn to vibe code before they learn to actually code, they won't develop the debugging and architectural thinking skills they need when the AI-generated code breaks. AI augments engineering skill — it doesn't replace it. Not yet.