Vibe coding isn’t bad by itself. It’s risky when it’s used for the wrong job.
The term describes building software by describing what you want in plain English and accepting the AI’s output largely on trust — often without reading every line it produces. That’s different from using AI to write code and then reviewing it, sometimes called agentic engineering instead:
| Vibe coding | Agentic engineering | |
|---|---|---|
| Who reads the diff | Rarely anyone | A human, before it merges |
| Best suited for | Prototypes, scripts, weekend projects | Anything shipping to real users |
| What catches mistakes | Nothing, until something breaks | Code review, tests, security checks |
For weekend experiments, skipping the review is a fine trade-off. For anything touching real user data, the research points to a genuine source of risk.
Security researchers have documented specific, repeatable failure patterns in AI-generated code: missing access controls, hardcoded secrets, hallucinated dependencies. These show up at rates high enough to track as a category, not a coincidence. At the same time, the same tools have opened software creation to people who never would have shipped anything otherwise. Both things are true — which one matters more depends entirely on what’s being built.
Andrej Karpathy, the AI researcher who coined the term in February 2025, described it as a workflow where the coder fully gives in to the vibes — stops reading the diffs, pastes error messages back into the model with no comment. He called it fine for weekend projects. He never called it a production methodology.
Why Do People Say Vibe Coding Is Bad?
The core complaint isn’t about speed. It’s about what gets skipped to get that speed: security review, architectural planning, an actual understanding of what the code does.
That pattern has a name in the research literature now — the gap between code that runs and code that’s safe to run. Researchers at Carnegie Mellon built a benchmark called SusVibes to measure exactly that gap, using 186 real feature requests from open-source projects:
- Functionally correct code: the best-performing agent hit 61%
- Also secure: only about 10.5% of solutions passed security checks
- Prompting for security: didn’t close the gap
That’s not a prompting problem. It’s structural — functional correctness and security are separate properties, and passing one doesn’t predict passing the other.
Veracode tested over 100 large language models on security-sensitive tasks and found a similar pattern:
| Metric | Result |
|---|---|
| Samples with an OWASP Top 10 vulnerability | 45% |
| Failed to defend against cross-site scripting | 86% |
| Vulnerable to log injection | 88% |
| Security pass rate, held flat across testing cycles | ~55% |
Some newer models have narrowed the gap slightly. The underlying pattern hasn’t moved — these models write code that runs faster than they write safe code.
Is There a Real Example of Vibe Coding Going Wrong?
Yes. Moltbook, an AI-agent social network, is the case study the industry keeps returning to.
Its founder, Matt Schlicht, said publicly that he built the entire platform by prompting AI rather than writing code himself. Within days, security firm Wiz found a misconfigured database exposing sensitive data to anyone who looked.
What actually broke: an exposed Supabase API key sitting in the platform’s front-end code, combined with a missing Row Level Security policy on the database behind it. That combination let anyone read and write to Moltbook’s entire production database without logging in.
What it exposed:
- 1.5 million API authentication tokens
- Roughly 35,000 email addresses
- Private messages between users
Wiz’s head of threat exposure called it a textbook case of unchecked AI-generated code reaching production.
Moltbook isn’t an isolated incident. Georgia Tech’s Systems Software & Security Lab runs a project called the Vibe Security Radar, built to trace vulnerabilities back to AI-generated code — and the count has been climbing fast:
| Month (2026) | CVEs attributed to AI-generated code |
|---|---|
| January | 6 |
| February | 15 |
| March | 35 |
A separate review of 50 vibe-coded applications found 88% had that same safeguard, row-level security, disabled entirely rather than simply misconfigured.
Does Vibe Coding Create Technical Debt?
Yes, and the mechanism is specific. AI models tend to solve each new problem from scratch rather than reusing or extending existing code. GitClear’s research found an eightfold increase in large blocks of duplicated code as AI coding tools became standard — more code doing the same thing in different places means more places a bug can hide.
The cost shows up later, not immediately, which is why it’s easy to underestimate while building. One analysis describes a pattern that plays out over roughly six to twelve months:
- Fast start — features ship quickly
- Rising bugs — regressions climb as the codebase grows
- Lost trust — developers stop trusting what they didn’t write
- Refactoring becomes mandatory — simple changes take longer than they should
This is the same failure mode researchers are now documenting in frontier models that outgrow their own creators’ understanding — a system built fast enough that nobody, including the people who built it, can fully explain what it does.
Industry estimates, not a single audited dataset, put a number on how often this plays out commercially: roughly 10,000 startups shipped production apps with AI coding tools by the end of 2025, and over 8,000 reportedly needed a partial rebuild or rescue engineering by mid-2026, at an estimated $50,000 to $500,000 per app.
Is Vibe Coding Making Junior Developer Jobs Harder to Get?
Vibe coding is reshaping the entry-level job market rather than eliminating it outright. AI handles exactly the tasks junior developers traditionally cut their teeth on — boilerplate, simple CRUD work, routine bug fixes. That shrinks the on-ramp, not necessarily the profession, and it echoes a pattern showing up across other entry-level fields, where graduates increasingly clear the interview but still can’t land the job.
Stanford’s Digital Economy Lab has the most rigorous data on this, tracking employment through ADP payroll records rather than surveys:
- Employment for 22-to-25-year-olds in AI-exposed roles, including software, runs about 19% below where it would sit had it kept pace with less-exposed peers the same age — up from a 15% gap a year earlier
- In raw numbers, employment for that age group in the most exposed roles fell about 11% between late 2022 and mid-2026, while it grew in less-exposed occupations
- Experienced workers in the same jobs show no comparable gap
Stanford’s own researchers describe this as a documented pattern, not proof that AI alone caused it — interest rates and a broader tech hiring slowdown overlap with the same period. That’s a narrower, better-supported claim than “AI is killing coding jobs.” The on-ramp has gotten steeper. The ceiling for experienced engineers hasn’t moved.
Who Said AI Would Make Everyone a Programmer?
Nvidia CEO Jensen Huang has made this case repeatedly: natural language is now a programming language, so the skills gap in software has effectively closed.
“There’s a new programming language… it’s called ‘human.'” — Jensen Huang, London Tech Week 2025
Critics, mostly people who write software for a living, counter that Huang — a hardware executive, not a programmer — is conflating code that runs with software that’s understood. Learning to code also teaches precise thinking and a working sense of how computers behave, neither of which a prompt teaches the person typing it.
Huang is right that the barrier to producing working code has collapsed. Critics are right that producing code and understanding it are different skills — and only one of them scales safely.
When Is Vibe Coding Actually Safe?
The honest answer scales with what’s at stake, not with a fixed rule:
| What you’re building | Vibe coding alone | Why |
|---|---|---|
| Personal script, throwaway prototype | 🟢 Fine | Small blast radius if something breaks |
| Landing page, mockup | 🟢 Fine | Limited attack surface |
| Internal tool touching company data | 🟡 Review first | Depends on access controls |
| SaaS app with user accounts | 🟡 Review required | Real users, real data |
| Payments, health records, auth | 🔴 Don’t ship unreviewed | This is exactly where Moltbook happened |
A reasonable working rule, drawn from where the incidents keep happening: if you can’t explain what the code does when something goes wrong, it isn’t ready to hold anyone else’s data.
So Is Vibe Coding Actually Bad?
Vibe coding is a tool. It’s well-suited to low-stakes work and increasingly risky as the stakes rise, with the review step being what actually determines the outcome.
The failure mode isn’t the AI writing bad code occasionally — every developer does that. It’s a workflow that, by design, skips the step that would normally catch it.
Not instead of AI-assisted development. In addition to it. The evidence doesn’t say AI-generated code is inherently unsafe. It says code that nobody has verified is unsafe, and vibe coding is currently the workflow most likely to skip that verification.
FAQs
Q. Is Vibe Coding Good for Beginners?
Yes, vibe coding can be a useful way for beginners to experiment with software and learn by building. It lowers the barrier to creating working prototypes without requiring deep programming knowledge upfront. The important distinction is between experimenting and shipping: beginners still need to learn how to read, test, debug, and review AI-generated code.
Q. Is Vibe Coding Cheating?
No, vibe coding isn’t inherently cheating; it’s a form of AI-assisted software development. Developers have always used tools such as documentation, search engines, libraries, and code editors to work faster. The real issue isn’t who wrote every line, but whether the developer understands, tests, and takes responsibility for the code.
Q. Will Vibe Coding Replace Programmers?
Vibe coding is more likely to change programming jobs than eliminate programmers altogether. AI can already handle much of the repetitive work involved in boilerplate, CRUD features, and simple fixes. Developers are still needed for system architecture, security, debugging complex problems, reviewing code, and making decisions when the requirements aren’t straightforward.
Q. Is Vibe Coding Safe for Production Apps?
Vibe coding is not safe for production applications when AI-generated code is shipped without human review. Code can appear to work correctly while containing security vulnerabilities, poor architectural decisions, or hidden technical debt. Production software should go through code review, testing, dependency checks, and security validation before it reaches real users.
Q. Can a Vibe-Coded App Pass a Security Audit?
Yes, a vibe-coded application can pass a security audit, but the generated code may need review and remediation first. Functional correctness doesn’t guarantee security. Developers should specifically examine authentication, authorization, input validation, data handling, dependencies, secrets, and common vulnerabilities before considering the application ready for an audit.
Q. What Should Developers Learn if AI Writes the Code?
Developers should learn system design, debugging, testing, code review, and security fundamentals even when AI writes much of the code. The ability to understand AI-generated code is becoming increasingly important. Developers need to know how components interact, where data flows, what can fail, and whether the resulting software is safe to deploy.
Q. What Are the Biggest Risks of Vibe Coding?
The biggest risks of vibe coding are security vulnerabilities, technical debt, poor architecture, and code that becomes difficult to maintain. These problems are easy to overlook because AI can produce a working result very quickly. The risk increases when generated code is copied repeatedly or shipped without someone understanding how it works.
Q. When Is Vibe Coding Safe?
Vibe coding is generally safest for low-risk projects such as personal scripts, prototypes, experiments, and mockups. The required level of review should increase with the consequences of failure. Applications handling authentication, payments, health records, company data, or other sensitive information should never rely on unreviewed AI-generated code.
Q. What’s the Difference Between Vibe Coding and AI-Assisted Coding?
The main difference is the level of human oversight. AI-assisted coding uses AI to generate or modify code while a developer reviews, tests, and validates the result. Vibe coding usually describes a more hands-off approach where the developer relies heavily on AI-generated output rather than examining every implementation detail.
Q. Is Vibe Coding the Same as AI Coding?
No, vibe coding is a specific approach within the broader category of AI-assisted coding. AI coding includes using artificial intelligence to generate, explain, debug, refactor, or modify software. Vibe coding generally involves describing the desired result in natural language and allowing AI to handle much of the implementation.
Q. Why Do Companies Let Developers Use Vibe Coding?
Companies allow vibe coding because the speed advantage can be significant during prototyping and early product development. Teams can test ideas and build internal tools faster with fewer manual coding hours. The trade-off is that organizations need proper review and maintenance processes to prevent that early speed from becoming long-term technical debt.
Q. Should You Use Vibe Coding for a Production Application?
Yes, AI coding tools can be used to build production applications, but the output should not be trusted blindly. A production workflow still needs human code review, automated testing, security checks, dependency management, monitoring, and documentation. AI can accelerate implementation, but the development team remains responsible for deciding what is safe to ship.
Related: 11 Best Agentic AI Frameworks in 2026: A Complete Decision Guide
| Disclaimer: This article is for informational purposes only. AI-generated code can contain errors or security issues, so always review and test it before using it in a live application. Research, statistics, and industry trends may change over time. |
