The Vibe Coding Trap: You're Just Producing Garbage Faster

Vibe Coding makes you produce garbage faster—efficiency isn't value, and judgment is what's truly scarce.
Vibe Coding lets anyone build apps and websites quickly with AI, but making something isn't the same as succeeding. This article reveals the core trap—efficiency gains don't equal value gains—and offers the right approach: find real problems and users first, then use AI to accelerate. Judgment, not code, is the truly scarce resource.
When Writing Code Is No Longer the Barrier
Recently a term has been getting a lot of people excited—Vibe Coding. Simply put, you don't need to write code seriously, and you don't need to deeply understand technology. As long as you can converse with AI, it can help you build websites, make apps, create tools, set up backends, and construct databases.
It's worth noting that the term Vibe Coding didn't appear out of nowhere. It was officially proposed and named by Andrej Karpathy, OpenAI co-founder and former Tesla Director of AI, in early 2025, and quickly became a buzzword in tech circles. Its core idea is: developers no longer write and review code line by line, but instead describe their intent to AI in natural language, letting large models automatically handle code generation, modification, and debugging. Karpathy described this state as "fully immersed in the vibes, almost forgetting the code itself exists." Behind this lies the leap in large language models' code generation capabilities, along with the maturation of a whole suite of AI programming tools.
In the past, if you wanted to build a product, you had to know frontend, backend, and deployment. Now you just say "help me build an app like such-and-such," and the AI gets to work. Pages, buttons, logos appear instantly, the official website is there too, login and registration are figured out, and even those fancy-looking pricing pages, user reviews, product introductions, and FAQs can all be arranged for you.
You stare at the screen and suddenly feel like you've leveled up. But Bilibili creator Haozi said something rather unpleasant in his latest video: many people, after mastering Vibe Coding, don't become creators—they become more efficient garbage producers.
Efficiency Up 67x, But Value Stays at Zero
Before AI existed, an ordinary person wanting to build an app was actually quite inefficient. A whole weekend of struggle might only produce a half-finished product—ugly interface, terrible features, tons of bugs, no logo, no website, no users, and certainly no revenue.
This thing was of course useless, but it had one hidden benefit: because it was slow to make, it actually blocked a lot of garbage ideas. Building a bad project still costs you time, energy, and resources, and you get forcibly educated by reality—does anyone actually want this thing?

Now that AI has arrived, efficiency has exploded. In one weekend you might make sixty or seventy apps, each with a name, a logo, a beautiful official website, and a slogan that sounds impressive. But the problem is—every single app has zero users.
Haozi offered a brilliant analogy: before, you could only print one piece of waste paper a day; now you can print sixty-seven pieces of colorful waste paper a day. The paper is more beautiful, the layout more sophisticated, the titles look more like startup projects, but still nobody needs it. Efficiency has genuinely improved, but value hasn't improved at all in sync.
"Making It" Is Not the Same as "Building Something Successful"
The biggest threat of Vibe Coding is that it makes people mistake "not having built anything" for "having succeeded."
Many people now open Cursor, Claude Code, or Codex, whip up a website in a few hours, and get excited: "I can develop too now, I can make products too, are programmers going extinct?"
The three tools mentioned here represent typical forms of current AI-assisted programming tools. Cursor is an AI-native code editor built on a deeply modified version of VS Code that can understand an entire project's context and generate whole blocks of code from natural language; Claude Code is a command-line AI programming assistant from Anthropic, good at handling complex multi-file engineering tasks; Codex originated from OpenAI and is one of the technical foundations behind GitHub Copilot. These tools have boosted the efficiency of "intent-to-code" conversion by tens of times, making it possible for one person to independently complete development work that used to require an entire team. But the more powerful the tool, the more it tests the user's judgment.
Calm down a bit—you've only had AI turn an idea into an interface, and an interface is by no means a product.
The truly hard part of a product has never been writing code, but rather: Who needs it? Why do they need it? How do users currently solve this problem? Are they willing to change their habits for your solution, willing to pay? Will they come back after using it? How will you sell it?

AI won't solve any of these for you. AI can help you generate code, but can't make business judgments for you; it can help you build pages, but can't find real needs for you; it can help you draw a beautiful website, but can't bring you your first paying user.
"Demo Machines" That All Look Alike
Have you noticed that things made with Vibe Coding these days all look very similar?
The homepage has a big headline "Change the Way You Work with AI," below it three selling points "More Efficient, Smarter, Simpler," then feature cards "AI Generation, Auto Analysis, One-Click Export, Smart Recommendations," and finally a few fake-as-can-be user reviews "This tool completely changed my workflow, I save three or four hours every day."

Once you click in, you'll discover: the features are cobbled together, the flow is fake, the data is fabricated, the scenarios are empty, and there are no users. The biggest characteristic of this kind of product is—every part looks like a product, and every part isn't a product. It's more like a showroom model that's beautifully decorated but has absolutely no one living in it.
A Brutal Divergence Is Coming
Haozi predicts a brutal divergence will emerge in the future.
The first type of person uses AI to quickly make demos: today an AI accounting app, tomorrow a resume tool, the day after an AI travel planner. Every project gets posted on WeChat Moments and Xiaohongshu. In the end they have a pile of links, a pile of screenshots, a pile of project names—but no users, no revenue, no repeat purchases, no assets.
The second type of person only makes some very small tools, so small they're not the least bit sexy. For example, automatically organizing customer inquiries, automatically generating quotes, automatically turning orders into travel reminders. They're not cool, not sexy, don't look like they'll change the world, but they solve a real problem—someone is willing to stick with using them, someone is willing to pay, someone can't do without them after using them.
This is the real gap: it's not about who can make sixty or seventy apps a day, but about who can turn a small problem into something real, usable, verifiable, and monetizable.
AI Amplifies Ability, and Also Amplifies Garbage
AI amplifies your abilities, and also amplifies your garbage ideas.
- If you have industry experience, AI will help you implement quickly; if you have user insight, AI will help you validate quickly; if you have aesthetic sense, AI will help you produce visuals faster.
- The reverse is also true: if you lack judgment about needs, AI will help you make something nobody wants faster; if you lack product capability, AI will only help you pile up features faster; if you lack distribution capability, AI will only help you make isolated-island projects faster.
After many people start using AI, they appear busier on the surface—making new things every day, trying new tools, posting screenshots, saying "I launched another new project." But ask them one question: How many real users do you have? How many people are paying? The answer is often silence. This isn't entrepreneurship, this is arts and crafts class.
The Right Order: Needs First, Code Later
So how should ordinary people actually use Vibe Coding?
It certainly has value, and its greatest value is driving down the cost of validation. In the past, if you had an idea you had to find someone to develop it, spend money, and wait through the cycle; now you can quickly make a small version and hand it to users to try.
This actually echoes the core methodology of the Lean Startup. The MVP (Minimum Viable Product) concept proposed by Eric Ries in The Lean Startup advocates using minimal cost to quickly build a version containing only core features, deploying it to real users, and rapidly validating hypotheses through the "build-measure-learn" loop, avoiding overinvesting resources in the wrong direction. Traditionally, the biggest obstacle to an MVP was precisely the high development cost and long cycle. The true significance of Vibe Coding lies in pressing the cost of the "build" link down to extremely low. But note, it only solves the building part—"measure" and "learn" still depend on you.
So the order absolutely cannot be wrong. The correct order should be:
- First find a real problem
- Then find real users
- Then do minimal validation
- Finally, let AI help you accelerate development
Many people do exactly the reverse: first let AI write code, then make a logo, build a website, write promotional copy, and only at the end remember to ask, "Who exactly am I selling this thing to?" Once this order is wrong, it's basically doomed. You can't build a car first and then go around asking who wants to head this direction; you should first know where someone wants to go, then decide what kind of car to use to get them there.
Three Questions for Judging the Value of a Vibe Coding Project
To judge whether a Vibe Coding project has value, you can't look at how pretty it is, but rather three things:

- Is anyone willing to use it—are there users who genuinely want to open it, use it, and hand their problems over to it.
- Is anyone willing to use it repeatedly—using it once might just be trying something new; repeated use shows it has truly entered the workflow.
- Is anyone willing to pay for it—money is the most real feedback. Users saying "I need it" and actually paying for it are two completely different things.
If a product has no usage, no repeat usage, no payment, then no matter how pretty it is, it's just an exquisite ornament.
Creation Gets Cheaper, Judgment Gets More Expensive
So don't be fooled by Vibe Coding's speed. Making sixty or seventy apps in one weekend sounds terrifying, but if none of them have users, it essentially means you've used AI to automate ineffective labor. In the past you produced garbage inefficiently; now you produce garbage efficiently.
In the future, AI programming will make "creation" cheaper and cheaper, but precisely because creation gets cheaper, judgment will get more and more expensive. More and more people can write code, more and more people can make demos, more and more people can generate logos and websites—what's truly scarce are those who can see clearly what the real needs are.
There's nothing to be proud of in mastering Vibe Coding. Only when what you build has users, has people paying, has people who can't do without it—that's worth being proud of. Otherwise, those so-called efficiency gains are just turning one useless app into sixty or seventy even more useless apps. This isn't awkward, this is a "capacity upgrade for garbage."
Key Takeaways
Related articles

Godot Engine VR Development Log: Lessons and Pitfalls from Porting to PSVR2
An in-depth analysis of an indie developer's experience using Godot to develop VR games and port to PSVR2, covering OpenXR integration, performance optimization, and console certification challenges.

What Are AI Model Weights, Really? The Deep Learning Truth Revealed by a Meme
Starting from a viral Reddit meme, we dive deep into AI neural network weights — what they are, why they can't be read visually, and how open weights drive technological democratization.

PDF Document Auto-Classification in Practice: Why Embedding Models Fall Short and Better Alternatives
Analysis of why embedding models (like bge-m3) fail at PDF document classification, covering label sensitivity and semantic dilution issues, with three better approaches: LLM classification, supervised classifiers, and multimodal feature fusion.