Vibe Coding: What It Actually Produces

Vibe coding — the workflow where you describe what you want and let AI write the code — has a marketing problem. The marketing is done by people posting "I built a SaaS in 20 minutes" on Twitter with a screen recording that ends before the first bug report. The result is a massive expectations gap between what vibe coding demonstrably produces and what people think it produces. I've spent the last two months deliberately vibe coding across multiple tools and project types, and the honest answer is more nuanced than either the hype or the backlash suggests.

Vibe coding is a real workflow that produces real output. It is not a replacement for software engineering. These two facts coexist without contradiction, and most of the discourse around vibe coding pretends they don't.

What It Actually Does

Let me define the term precisely, because it's gotten muddy. Vibe coding means prompt-driven development: you describe your intent in natural language, an AI tool generates the code, you review and iterate through conversation rather than writing code line by line. The "vibe" part is that you're steering the output at the level of behavior and feel rather than implementation detail. "Make the sidebar collapse on mobile with a smooth animation" instead of writing the CSS transitions and JavaScript event handlers yourself.

The tools that enable this sit on a spectrum from "AI-assisted IDE" to "no-code with AI." At the coding end: Cursor's Composer mode and Claude Code, where a developer describes changes and reviews generated diffs. At the app-builder end: Bolt.new, Lovable, Replit Agent, and v0, where you describe an entire application and get a running result. The further you move toward the app-builder end, the more "vibey" the workflow — and the more the 80/20 problem applies.

What vibe coding produces well, across the spectrum:

Prototypes and MVPs. This is the sweet spot. Describe an app, get a working version in 15-60 minutes, show it to people, learn what they actually want. I built a functional task management app with Lovable in 40 minutes — user auth, CRUD operations, a clean UI. It worked. It was not production-ready, but it was good enough to demonstrate the concept and collect feedback. Before vibe coding, that prototype would have taken a weekend.

Landing pages and marketing sites. V0 and Bolt.new are genuinely excellent at this. Describe the page, iterate on the design, deploy. I tested v0 against a designer's Figma mockup and the output matched about 80% of the design on the first generation. Two rounds of iteration got it to 95%. The remaining 5% was pixel-level tweaking that took longer in v0 than it would have in raw CSS, but the total time was still less than building from scratch.

Internal tools. The kind of app that three people at a company use to track inventory or manage a workflow. These have low traffic, forgiving users, and simple requirements. Vibe coding handles them well because the tolerance for rough edges is high and the feature set is small.

Boilerplate and scaffolding. Even for production projects, using vibe coding to generate the initial structure — project setup, API routes, database schema, basic CRUD — saves real time. A senior developer can describe the architecture, let the AI generate the skeleton, then take over for the complex parts. This is vibe coding at its most practical and least controversial.

What vibe coding does not produce:

Complex production systems. Anything with non-trivial state management, concurrent operations, complex authorization rules, or performance requirements will break vibe coding's back. I attempted to build a collaborative document editor — real-time sync, conflict resolution, offline support — through pure vibe coding with Bolt.new. After three hours, I had something that looked like a document editor and crashed when two users edited simultaneously. The gap between "it looks right" and "it works right" was unbridgeable through prompting alone.

Security-critical applications. Vibe-coded apps handle authentication at a surface level — they'll add a login form and session management — but they don't handle the edge cases that matter: CSRF protection, rate limiting, input sanitization beyond the basics, secure session storage, proper secret management. Users on r/webdev report finding SQL injection vulnerabilities in vibe-coded apps that passed basic testing [VERIFY — specific community reports of SQL injection in AI-generated code]. If your app handles payments or sensitive user data, vibe coding the security layer is malpractice.

Anything you need to maintain. This is the problem nobody talks about on demo day.

What The Demo Makes You Think

The demo makes you think the hard part is over. The app runs, it looks good, the basic features work. Ship it. What the demo doesn't show is day 30.

The 80/20 wall is real and I hit it on every vibe-coded project. The first 80% of functionality comes together in the first 20% of the time. Then you start on the remaining 20% — error handling, edge cases, loading states, empty states, validation, accessibility, performance, mobile responsiveness done properly rather than "it technically scrolls" — and the speed advantage evaporates. Each fix requires describing the problem in enough detail that the AI understands the context, waiting for generation, reviewing the output, finding that the fix broke something else, describing the regression, waiting again. After 15-20 rounds of this, I was consistently faster just opening the codebase in Cursor and fixing things manually.

The maintenance problem is worse than the generation problem. When you vibe code an application, you end up with a codebase you didn't write and may not fully understand. The architecture reflects the AI's defaults, not your decisions. The naming conventions are whatever the model chose. The state management approach might not be what you'd have picked. This is fine on day 1. On day 30, when a user reports a bug and you need to trace the data flow through code you've never read line by line, you're debugging someone else's code — except the someone else is a language model and you can't ask it what it was thinking because the conversation context is gone.

I tracked the time on a vibe-coded project from generation through one month of maintenance. The initial build took 2 hours. Bug fixes and feature additions over the next month took 14 hours. At least 6 of those 14 hours were spent understanding code the AI had written rather than fixing the actual problems. A developer who wrote the code from scratch would have spent more time upfront but dramatically less time on maintenance, because they'd understand every line.

The social media posts also create a survivorship problem. You see the "I built X in 20 minutes" successes. You don't see the far more common "I spent 4 hours trying to get the AI to fix a bug it created and eventually gave up" failures, because nobody posts those. The people most likely to succeed with vibe coding are experienced developers who can evaluate and fix the output — exactly the people who would benefit least from the "no coding required" promise.

What's Coming (And Whether To Wait)

Vibe coding is going to get better. The models are improving at code generation every quarter, context windows are growing, and the tooling is maturing. Specific things to watch:

Better debugging loops. The weakest part of vibe coding is iteration — fixing the last 20%. Tools like Lovable and Bolt.new are investing heavily in error detection and self-healing, where the AI notices a runtime error and fixes it automatically. According to Lovable's changelog, their error auto-fix resolves about 40% of runtime errors without user intervention [VERIFY — Lovable's auto-fix success rate is from their own reporting]. If that number reaches 70-80%, the 80/20 wall gets pushed back significantly.

Persistent project context. The biggest technical limitation is that vibe coding tools lose context between sessions. You build something today, come back tomorrow, and the AI has forgotten the decisions it made. Longer context windows and better memory systems are coming — Claude's 200K context window is already helping — and persistent project understanding would make iteration dramatically better.

Hybrid workflows. The most promising direction isn't pure vibe coding but what you might call "vibe scaffolding" — use AI to generate the 80%, then switch to manual coding for the 20% that requires precision. Cursor's Composer is already this workflow. As the app-builder tools add better code export and IDE integration, the handoff between vibe mode and precision mode will get smoother.

Should you wait for these improvements before vibe coding? No, but you should calibrate your expectations to what the tools do today rather than what they'll do in a year. Use vibe coding for what it's good at now — prototypes, MVPs, internal tools, landing pages — and reach for traditional development when the project demands it.

The Verdict

Vibe coding is not a revolution in software development. It is a new tool in the toolkit, and like every tool, it has a domain where it excels and a domain where using it is the wrong choice.

The domain where it excels: getting from zero to something people can use and evaluate, fast. Prototypes, demos, MVPs, internal tools, personal projects, landing pages, hackathon entries. If the answer to "what happens when this app breaks at 2 AM" is "nothing important," vibe coding is probably fine.

The domain where it fails: production applications that need to be reliable, secure, maintainable, and performant. Anything that will have users who depend on it. Anything you'll need to debug six months from now. Anything handling money or sensitive data.

The people who benefit most from vibe coding are, ironically, experienced developers. They can evaluate the output, fix what's wrong, understand the architectural decisions, and know when to stop prompting and start typing. Non-developers can use vibe coding to build simple things — and that's genuinely valuable, it wasn't possible two years ago — but they'll hit a ceiling faster and harder than the demos suggest.

The honest framing: vibe coding has made it dramatically faster to build things that are 80% done. It has not changed how hard it is to build things that are 100% done. The gap between those two numbers is where software engineering lives, and it's wider than a prompt can bridge.

If you're a developer, vibe code your prototypes and scaffold your projects. Then write the production code yourself — or at least with a tool like Cursor or Claude Code where you're reviewing every line, not hoping the vibes carry you through. If you're not a developer, vibe code your internal tools and MVPs, but budget for a developer when things need to be real. The 20-minute build is real. The 20-minute production app is not.

Updated March 2026. This article is part of the Code Generation & Vibe Coding series at CustomClanker.