The criticism of vibe coding is real, and some of it is warranted. Apps have shipped with exposed database credentials. Codebases have become unmaintainable after a single vibe-coding session created thousands of lines with no consistent architecture. Developers worry about skill atrophy. Security researchers have found vulnerabilities in AI-generated code that would not have passed review from an experienced engineer.
But "is vibe coding bad" is the wrong question. The right question is: bad compared to what, for whom, and at what stage? A non-technical founder shipping an MVP with Lovable is not replacing a senior engineering team. They are doing something they could not do at all before. The relevant comparison is not vibe-coded app vs. perfectly engineered app. It is vibe-coded app vs. no app.
This piece takes the criticism seriously, names the real failure modes with specifics, and lands on an honest verdict: vibe coding is a powerful tool with genuine risks that are manageable with known mitigations. It is the wrong tool in identifiable scenarios. For the right use cases, it is genuinely transformative.
What this covers
- ✓ The specific security risks in vibe-coded apps (with documented examples)
- ✓ The skill atrophy concern and who it actually affects
- ✓ Technical debt patterns unique to AI-generated codebases
- ✓ When vibe coding is genuinely the wrong tool
- ✓ The honest case for vibe coding despite its problems
What the critics are actually saying
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.
Where vibe coding actually goes wrong
Security: Skipped review is the failure mode
The security failures in vibe-coded apps have a consistent pattern: the developer shipped without running a security review. AI tools do not add row-level security policies in Supabase unless prompted. They do not add rate limiting to auth endpoints unless asked. They do not warn you when an API key is about to be included in client-side code unless you have that configured. The solution is a pre-launch security checklist, not avoiding AI coding.
Technical debt: Architecture decisions accumulate silently
Each vibe coding session makes implicit architectural choices. Over 30 sessions, a codebase can have three different patterns for data fetching, two approaches to error handling, and inconsistent typing. The debt compounds slowly and becomes visible when you try to add a feature that touches multiple parts of the system. A project-level .cursorrules file that enforces consistent patterns reduces this significantly. Without it, the debt is real.
Skill atrophy: Real for developers, not founders
A developer who uses AI to skip learning how things work does not build the debugging intuition that comes from fixing things. This matters for developers who will maintain systems long-term, join teams with existing codebases, or need to reason about performance tradeoffs. For non-technical founders, the skill atrophy concern is inverted: they are gaining capability they never had. The concern is legitimate but targeted, not universal.
Accountability gap: Who fixes it when it breaks?
In a traditionally coded system, the engineer who wrote a module usually understands it. In a heavily vibe-coded system, the "author" may be a non-technical founder who used Lovable to generate 10,000 lines and understands none of it at the implementation level. When a production incident happens at 2am, the accountability gap is real. This is the strongest structural argument against vibe coding for any system where availability or correctness is critical.
When vibe coding is the wrong tool
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.
The honest case for vibe coding despite its problems
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.
The problems and their mitigations
| Problem | Who it affects | Mitigation |
|---|---|---|
| Security vulnerabilities shipped without review | Anyone launching to real users | Pre-launch security checklist; Supabase RLS audit; API key scanning |
| Technical debt from inconsistent architecture | Projects built over many sessions | .cursorrules file with enforced conventions; periodic refactoring sprints |
| Skill atrophy | Developers in early career | Read and understand generated code before accepting; ask AI to explain decisions |
| Accountability gap in incidents | Teams and production systems | Document architecture decisions; code review before merge even for AI output |
| Performance unoptimized | Apps expecting high traffic | Load test before launch; prompt specifically for query optimization |
| Not suitable for regulated data | Healthcare, finance, PII | Expert security review before launch; do not ship without it |