What Is Vibe Coding? A Developer's Honest Assessment

What is vibe coding, exactly? You describe what you want in natural language, an AI model generates the code, and you steer with follow-up prompts instead of editing files by hand. That is the definition. The version that matters for your daily work is different: vibe coding is broken by default for most teams, not because the tools are bad -- they are genuinely good -- but because the feedback loop is too fast and the review step gets skipped.

Karpathy coined the term in 2025 -- here is what he meant

Andrej Karpathy posted a short thread in February 2025 describing how he was building apps by narrating intent to a large language model and accepting the output without reading most of it. He called it vibe coding. The phrase stuck because it named something a lot of developers were already doing informally, without a label for it.

The working definition: you describe what you want in natural language, the AI writes the code, and you steer with follow-up prompts rather than editing files by hand. The vibe in the name is genuine -- you are cueing the model on behavior, tone, and constraints rather than specifying line-level logic. Collins Dictionary named it their 2025 Word of the Year, which tells you how fast this moved from fringe practice to mainstream habit.

What Karpathy was actually describing was a mode of working with LLMs that prioritizes momentum over control. You do not read every line. You run the output, see what breaks, and re-prompt. The iteration loop is fast enough that you can build real things this way. That is the appeal. The risk is proportional to what those things are doing in production.

The 55% faster claim needs a footnote

The most cited number in this space is a 55% reduction in task completion time when using AI coding tools. That figure is real, but it comes from controlled studies on isolated, well-defined tasks. A 2025 METR study found that on complex tasks -- multi-file systems, debugging across layers, integration work -- developers using AI assistance were 19% slower than those working without it. You can be moving fast and losing ground simultaneously.

The pattern I see in my own backend work: prompting Cursor to scaffold a REST endpoint with basic validation takes under three minutes. Understanding and hardening what it generated takes fifteen to twenty minutes. If you count both steps, the math still favors using AI -- but not by 55%. On anything non-trivial, I come out 15-20% ahead, not 55. The tools that advertise speed are not lying. They are measuring the part they touch, which is the generation step, not the verification step.

The developer experience paradox makes this stranger: 80% of developers in a 2025 survey report preferring AI coding tools for manageability even when they clock slower on complex tasks. The feeling of progress is decoupled from actual progress. That is worth knowing before you commit your team to a vibe-first approach.

Where vibe coding genuinely works

Rapid prototyping is the clear win. You need a clickable demo by Thursday. The AI builds 80% of it in an afternoon. You clean the edges. That works, consistently. 25% of Y Combinator Winter 2025 startups shipped with codebases that were 95% AI-generated. Some of them raised money on those prototypes.

Routine boilerplate is the second win. Forms, list views, CRUD endpoints, pagination logic, auth scaffolding -- anything you have written thirty times before. Vibe coding is faster here because the correctness bar is stable and the patterns are well within the training distribution of every major model. Booking.com saw a 30% increase in merge requests after adopting GenAI tools internally. That is real throughput.

Solo projects with no handoff. If you are the only person who will ever read the code, and the project is small, the cost of opaque AI-generated output is close to zero. You iterate until the behavior is right. This is where vibe coding is most honest about what it is: a fast approximation that you converge toward correctness rather than construct from first principles.

Where it fails, and why the failure is quiet

The dangerous part of vibe coding is not that it produces bad code. It is that the bad code looks right. Syntactically valid, well-structured, plausible code that does not do what you intended. No error message. No lint warning. Just wrong behavior, sometimes only visible under load or at the boundary of your threat model.

I ran into this on a billing integration earlier this year. Cursor generated a webhook handler that validated signatures correctly in 98% of cases. The 2% was a specific replay attack vector that only surfaces at high request volume. The code read clean. The tests I prompted it to write did not cover the edge case because I did not think to specify it. That is the shape of the failure -- not a crash, but a gap in the logic that maps to a real exploit.

The aggregate numbers are worse. 45% of AI-generated code contains security vulnerabilities including hardcoded secrets or improper input validation. 170 of the first 1,645 apps built on Lovable in 2025 exposed personal data within weeks of launch. 1.5 million API keys and 35,000 email addresses were leaked in a breach traced back to AI-generated credential handling in early 2026. These are not rare outliers. They are a structural property of optimizing for code that looks correct rather than code that has been verified as correct.

63% of developers now report spending more time debugging AI-generated code than they would have spent writing equivalent code by hand. That is not an argument against these tools. It is an argument for building the review step into your process before you remove the manual writing step.

The tools doing the most real work in 2026

The market split into three categories. Natural-language app builders, AI-first code editors, and terminal or cloud agents. Each does a different job.

AI-first code editors. Cursor leads at $20/month Pro, with multi-file Composer mode that reasons across an entire codebase in one pass. It reached $2 billion in annualized revenue by early 2026 -- the fastest-growing developer tool in recent history. Windsurf ($15/month Pro) is the main alternative, with a memory layer that retains your architecture decisions and naming conventions across sessions. Both use the same underlying models but differ in how they surface and maintain context.

Terminal agents. Claude Code runs from your terminal, reads and writes files directly, and operates within a 200,000-token context window. That means it can hold a medium-sized codebase in a single pass without chunking. No IDE. No GUI. If your setup is already terminal-native, this fits without friction. One tool. One job. No Electron shell, no subscription to an editor you would not otherwise use.

Autocomplete with compliance constraints. Tabnine uses a smaller model trained on your company's codebase and runs locally or on-premise. It is slower and less dramatic than Cursor but does not send your source code to an external API. For teams under SOC 2, HIPAA, or similar compliance requirements, that distinction is not negotiable.

Autonomous agents. Devin and Replit Agent take a task description and run a full development cycle -- write, test, iterate, and deploy -- with minimal back-and-forth. Replit Agent includes hosting. These work well for self-contained features with explicit success criteria and no implicit organizational context.

Before you ship: the security check that cannot be skipped

Treat every AI-generated PR like it came from a developer who is fast, confident, and has not yet built intuition for your threat model. The review does not need to be exhaustive. It needs to cover the three failure modes that AI consistently misses.

Hardcoded credentials. Models default to illustrative code. They write API_KEY = "sk-example" as a placeholder, and that placeholder makes it to staging more often than it should. Run git grep for common patterns before every merge. It takes 30 seconds.

Input validation and trust boundaries. The model does not know which endpoints are user-facing or which fields arrive without sanitization. You do. Check every point where user input touches a database query, a subprocess call, or an external API.

Dependency names. AI-generated code pulls in libraries by name. Package hallucination -- where the model invents a plausible package name that does not exist, which a threat actor has since registered with malicious code -- is a documented attack vector. Verify every new dependency against the canonical registry before it lands in your lockfile.

Who should actually use vibe coding

If you are building a prototype that will never touch real user data: use every vibe coding tool available. Speed is the only metric that matters here, and these tools are unambiguously fast.

If you are a solo developer building a small commercial product: vibe coding with a structured review step -- prompt, generate, verify before each push -- is a net positive. You ship faster than you would without it, and a focused audit before each release keeps the security surface manageable.

If you are on a team shipping to production: the calculus is more demanding. Shared codebases drift toward incoherence when multiple developers are prompting independently without shared context or conventions. The 92% of U.S. developers now using AI coding tools daily are not all winning from it equally. The ones winning have built the review infrastructure first. The ones losing have added velocity without adding the verification to match it.

If you have [specific problem]: complex system with undocumented invariants, legacy integrations, or a threat model refined over years -- vibe coding is a developer who does not know your system. Use it for scaffolding. Own the logic yourself.