Is Vibe Coding Bad?

The loudest criticism of vibe coding comes from three groups: experienced engineers, security professionals, and computer science educators. Their concerns are different and worth separating.

Engineers worry about code quality and maintainability. AI-generated code often works in the moment but lacks the deliberate architectural decisions that make a codebase navigable in 18 months. Functions are named inconsistently. State management mixes patterns from different paradigms. Error handling is shallow. These are real problems, but they are also problems in codebases written by junior developers without senior review. The criticism is less about AI and more about the absence of engineering culture.

Security professionals worry about what gets shipped without review. Their concern is more immediate. A developer who does not understand the code they are shipping cannot know whether it is secure. In documented cases from 2025, vibe-coded apps were found to have: Supabase row-level security disabled (making all user data accessible via the public API), API keys embedded in client-side JavaScript, and authentication bypasses where the session token was not validated server-side. None of these vulnerabilities require exotic attack knowledge to exploit.

CS educators worry about what gets lost when students build apps without understanding how they work. The concern is that vibe coding gives the experience of building without the understanding that comes from struggling through the implementation. This concern is most valid for students in technical programs where engineering depth is the goal. For everyone else, the ability to build something is its own form of learning.

There are identifiable scenarios where the risks of vibe coding outweigh the benefits. This is not a theoretical list. These are the contexts where the failure modes documented above are most likely to materialize.

Regulated data without a review layer. HIPAA-covered health apps, financial applications handling payment data, and any system processing PII at scale require security review regardless of how the code was written. Vibe coding can produce the code, but the code cannot ship without expert review. Vibe coding without the review layer is the failure mode; vibe coding with the review layer is fine.

Performance-critical systems. AI tools produce working code, not necessarily efficient code. A search index that scans 10 million records on every query works in development and fails in production. Vibe coding the architecture of a high-throughput system without an engineer who understands database indexing, caching strategy, and query optimization is a performance debt bomb.

Large existing codebases without context. AI tools work best with full context of the codebase. A 500,000-line monolith is too large for any current AI tool to hold in context. Vibe coding features into a system like this without deep understanding of existing patterns, dependencies, and side effects is risky. The AI generates code that looks correct but breaks existing behavior in non-obvious ways.

Systems that will be maintained by others. If you vibe code an app and leave a job, the next engineer inherits a codebase they cannot understand because the "author" never understood it either. The accountability and maintainability gap becomes a hiring and onboarding problem.

Deep domain expertise requirements. Cryptographic implementations, operating system kernel modules, embedded systems firmware, and similar domains require expert precision that AI tools do not reliably provide. In these domains, a plausible-sounding wrong answer from an AI tool is more dangerous than an obvious error.

After taking the criticism seriously, the honest case for vibe coding remains strong. The key is understanding what changed and what has not.

What changed: The threshold to build working software dropped. A non-technical founder can now ship an app in a weekend without a developer. A solo engineer can build at the pace of a team. The economic cost of a software idea became hours instead of months. These are genuine, documented productivity gains measured in shipped products.

What did not change: Software engineering principles. Security review still matters. Architecture decisions still have long-term consequences. Understanding what your code does is still a prerequisite for maintaining it. Vibe coding changes who can write code, not the principles that make software reliable.

The framing that "vibe coding is bad" usually comes from comparing a vibe-coded app to an idealized traditionally coded app reviewed by senior engineers. But that idealized comparison is not the real alternative for most vibe coders. The real alternative is no app at all, or an app that takes 18 months and $300,000 in engineering costs. On that comparison, vibe coding wins by a wide margin for the majority of use cases.

The vibe coding guide covers the full workflow and which tools to use for different project types. Thecomparison between vibe coding and traditional coding goes deeper on where each approach wins.