What Is Vibe Coding?
Vibe coding is a software development practice where a person describes an application or feature in plain, conversational language, and a large language model (LLM) generates the code automatically. AI researcher Andrej Karpathy coined the term in February 2025 to describe coding where the developer stops reading the code and focuses only on the intended feel of the program. It spread fast enough to become Collins Dictionary’s Word of the Year. As tools like Cursor, GitHub Copilot, Claude Code, and Lovable matured, it grew from an experiment among senior engineers into a mainstream way for non-developers to build working software with no coding background.
For security teams, vibe coding matters because the speed that makes it appealing also removes the review steps that normally catch cybersecurity issues before production.
How Vibe Coding Works
The practice lives entirely in the trust between developer intent and AI output. The model has no way of knowing whether the fastest solution is also a secure one unless it is specifically prompted, and reviewed.
- Natural language prompt: The person describes the feature they want in a sentence or two, the way they’d explain it to a colleague.
- Code generation: The LLM turns that description into working source code, choosing the frameworks and logic on its own.
- Uncritical acceptance: If the result runs, the developer accepts it without reading the diff. Errors get pasted back into the chat rather than debugged by hand.
- Iterative refinement: The cycle repeats: intent in, code out, run, accept. The application grows through many small prompts, often outgrowing what its builder actually understands about it.

Simplified visualization of vibe coding
Vibe Coding vs. Agentic Coding vs. AI-Assisted Development
The three terms sit at different points on the same spectrum. AI-assisted development is the broadest: a developer who understands the codebase uses an LLM for suggestions and still reviews what it produces. Vibe coding drops that review step: the developer trusts the output on faith and iterates through natural language. Agentic coding goes further: an AI agent plans, writes, tests, and revises code across files with minimal prompting, sometimes without human review at all. Vibe coding is the “no hands on the keyboard, no eyes on the diff” end of that spectrum.
Limitations of Vibe Coding
Even used well, vibe coding has limits that good prompting alone doesn’t remove.
- Weak at architecture and scale: It holds up for prototypes, but larger projects accumulate inconsistent patterns since no single session holds a full plan for the system.
- Outdated by default: Models often default to older library or framework versions unless corrected.
- A widening understanding gap: Neither the builder nor whoever inherits the code can easily explain how it works, since the reasoning lived in a chat rather than in documentation.
- Inconsistent output: The same prompt can generate different code from one run to the next, which complicates debugging.
- Minimal testing by default: Generated code covers the case where everything goes right; edge cases and tests only appear when someone asks for them.
Security Risks of Vibe Coding
That trust translates into a recurring set of risk categories:
| Risk Category | Detection Difficulty | Primary Impact |
|---|---|---|
| Hardcoded secrets and credentials | Low to medium | Leaked API keys, tokens, and database passwords |
| Hallucinated dependencies (“slopsquatting”) | High | Malicious package installed at build or install time |
| Broken access control | Medium to high | Unauthorized access to other users’ data |
| OWASP Top 10 code flaws | Medium | Cross-site scripting, log injection, SQL injection |
| Insecure defaults and misconfigurations | Low once found, high beforehand | Full database exposure, Remote Code Execution (RCE) |
| Indirect prompt injection against coding agents | High | Agent hijacked into leaking data or running attacker commands |
The research backs this up. Veracode tested over 100 LLMs and found that roughly 45% of AI-generated code samples introduced at least one OWASP Top 10 vulnerability. That rate held steady through early 2026, even as the same models kept improving on general coding benchmarks.
Georgia Tech’s Vibe Security Radar project traces public CVEs back to the AI tool that generated the flawed code. It recorded the monthly count climbing from 6 in January 2026 to 35 by March, and researchers believe the real figure across the open-source ecosystem is several times higher. A scan of roughly 5,600 live apps built on popular vibe coding platforms found around 2,000 high-severity vulnerabilities in production, including exposed API keys and personal data.
LLMs also invent plausible package names that do not exist. Attackers pre-register those exact names on registries like npm and PyPI, a technique called slopsquatting, betting that a coding agent will install the fake package it just recommended.
Two 2026 incidents made the stakes concrete. An AI social platform leaked roughly 1.5 million auth tokens within days of launch, and a consumer app exposed private messages after unreviewed AI-generated backend logic shipped to production. See AI Hallucinations, Black Box AI, and Shadow AI for related concepts.
Prevention and Mitigation
Treat AI-generated code as untrusted third-party code: Every function an LLM writes should get the same review, static analysis (SAST), and dependency scanning (SCA) as a contribution from an unknown outside contributor.
Verify dependencies before installing them: Cross-check package names against the official registry before running an install command an AI assistant suggested. This is the direct countermeasure to slopsquatting.
Never hardcode secrets:
Vulnerable: api_key = “sk-live-51Hd8f…”
Secure: api_key = os.environ[“API_KEY”]
LLMs default to the first pattern unless told otherwise, since it’s the simplest way to make code “just work.”
Apply least privilege to AI coding agents: Any agent or service account used to generate, test, or deploy code should hold only the permissions its task requires.
Govern what can ship without review: Require mandatory security review for customer-facing or regulated-data applications. Enforce it in the CI/CD pipeline instead of relying on developer discipline alone.
Keep runtime defenses in place: A Web Application Firewall (WAF) and ongoing Third-Party Cyber Risk Management (TPCRM) over AI-introduced dependencies add defense-in-depth for whatever gets through review.
Tips for More Effective Vibe Coding
A few habits separate reliable output from a prototype that breaks under real use.
- Scope each prompt to one slice of the app: One feature at a time, such as auth before UI, catches mistakes early and keeps the output clean.
- Give it context it can’t infer: State the stack, conventions, and what already exists, since most tools start fresh each session.
- Review every diff before moving on: Read each change like a pull request from a new hire before building on top of it.
- Commit working versions as you go: Version control lets you revert cleanly when an AI “fix” breaks something else.
- Ask for error handling and edge cases explicitly: Left alone, models write code for the happy path only.
FAQ
Is vibe coding safe for production applications?
Only with the same controls applied to any other code: review, testing, and monitoring. Studies have found unreviewed vibe-coded apps in production carry far more exploitable vulnerabilities than human-written code, mainly because the workflow skips review by design.
What is slopsquatting?
A supply chain attack where threat actors register malicious packages under names LLMs are known to hallucinate, then wait for a developer’s AI assistant to recommend installing one.
Should organizations ban vibe coding outright?
Most researchers argue against a ban, since the productivity gains are real. The more workable path is governance: mandatory review for production code, and a clear policy on what can be vibe-coded freely without it.
