Insights on Vibe Coding and Its Commercial Value

Recently, I participated in a private discussion where we talked about Vibe Coding. Participants included product developers and content creators, and nearly everyone was using various AI tools to write code and create small applications. The core debate centered around one question: does this have any commercial value?

Those opposed to Vibe Coding argue that users create small tools, play with them for a couple of days, and then discard them, leading to very low retention rates and unviable business models.

I refrained from responding at the time because I felt the question itself was misguided. People were focusing on Vibe Coding from a supply-side perspective, concerned about what products were created, their usability, and user retention. This product manager mindset is not wrong, but it is misplaced in this context.

When viewed from the demand side, the situation looks entirely different.

Recently, I wrote an article and wanted to present the key points in a PowerPoint for a leader who prefers not to read dense text. I created a 10-page PPT that clearly outlined the themes, viewpoints, and details. After finishing the PPT, a new question arose.

I wanted to turn the same content into knowledge cards for social media. I tried several AIs, but none produced satisfactory results until I used Google’s NotebookLM.

Reflecting on this process, what lay behind those knowledge cards?

On the surface, they were AI-generated content, but fundamentally, they were a product of Vibe Coding; the AI understood my needs, wrote a piece of code, and rendered what I wanted. Throughout this process, I never thought, “I want to create an application.” Instead, I thought about transforming the article into a format suitable for my leader and shareable on social media.

The small application was merely a means to an end; the service was the goal. If it gets discarded after use, that actually indicates it fulfilled its purpose. I call this “service-level software”: first, there is a specific demand, and then corresponding software is generated to meet it; service comes first, software follows.

Thus, those who believe Vibe Coding lacks commercial value are measuring “service” against the standards of “products,” which require retention, repeat purchases, and user stickiness. Services do not.

When you visit a hospital for a single appointment, you wouldn’t say the visit was worthless just because you won’t return next time.

In March of this year, Sequoia Capital partner Julien Bek discussed a similar viewpoint: a company spends $10,000 a year on accounting software and $120,000 on accountants; the next great company will directly handle the accounting for you, as users want results.

Bek was addressing the B2B sector, where AI replaces traditional outsourcing services like bookkeeping and contract review. The core idea is to replace existing services.

However, I see a different opportunity at the C-end, within the smartphones of ordinary people.

I found that there are currently over 8 million lightweight applications in China, which sounds like a lot. But think about how many times you encounter a specific small problem, search the app store, and find no corresponding app?

The issue isn’t a lack of demand; it’s that the demands are too small, fragmented, and personalized.

I refer to these types of demands as “non-standard demands.” They might only be needed once, perhaps only a few dozen people require them, and no app covers them.

Creating even the simplest app can take weeks or even months from conception to launch, costing at least several thousand dollars. No developer finds it worthwhile to pay for non-standard demands.

While millions of apps seem to cover everything, they only address sufficiently large and generic standardized needs, leaving the long tail of non-standard demands unattended.

In the past, no one addressed these needs because service costs were too high. Now, Vibe Coding brings those costs down to nearly zero. In just a sentence and 30 seconds, a small tool exists solely for your unique problem.

Recently, I came across several cases that genuinely moved me.

One user in Henan created a “small microphone” for his father, who had suffered a stroke and could not communicate normally. The interface had only a few large buttons labeled “eat,” “sleep,” and “pain”. When the elderly man pressed a button, the phone would speak for him.

If you searched the app store for a “communication tool for speech-impaired elderly,” you would find nothing. This need has existed for decades, yet no developer deemed it worth creating a product.

Another example is a rural physics teacher who created a light refraction demonstration tool due to a lack of teaching aids. Students could drag a slider to see the light path change in real time. Rural schools cannot afford experimental equipment, and such needs have been ignored—not due to a lack of ability, but because it was not commercially viable.

This highlights the fundamental difference between the B-end and C-end.

B-end focuses on replacement; there were already services available, and AI reduces costs. C-end non-standard demands have never been served, and there is nothing to replace.

So, where is the commercial value of Vibe Coding?

It lies in releasing a previously unmet demand market. Individual demands may be too small to justify creating a product, but countless “not worth it” cases add up to a significant gap.

However, I’ve observed that current Web Coding products often tell the story backward.

Check the slogans of various companies: “Coding agents for everyone,” “Empower everyone to create applications,” “Intent programming”—all keywords emphasize “creating applications.”

But the user who created the “small microphone” for his father had a need to help his dad communicate, not to experience no-code programming. The rural teacher’s need was to show students how light bends, not to become a super individual.

These most touching stories are rarely seen in promotional materials.

What do you think they promote?

Relationship calculators, horoscope matching tests, and leave request generators. I saw one app that reminded users to drink water. My immediate reaction was: do you need to create an app for that? The built-in alarm on your phone is sufficient.

You incentivize the action of “creating an application” rather than the result of “solving a problem,” leading to outputs that easily become mere decorations.

Some platforms create communities for users to share their applications, receive likes, comments, and engage in secondary creation, mimicking the logic of short videos.

But flash applications are different from short videos.

Short videos have entertainment value; you might laugh at a funny segment or feel hungry watching a food video. But if you come across a relationship calculator? You might click in to try it, but then it ends there.

Other platforms spend money incentivizing creators to encourage more app development.

But the bottleneck is not on the supply side; there shouldn’t be a shortage of applications. The real issue lies on the demand side: most ordinary people don’t realize that the challenges in their lives can be solved this way.

It’s like having a bunch of gear in a game sitting in a warehouse, looking rich, but players can’t even find the entrance to their inventory.

So how do we turn this around?

I believe that Vibe Coding products are currently competing on daily active users, features, and generation speed. We need to change our thinking.

If we recognize the direction of “service-level software,” we should focus on those moments in users’ daily lives when they think, “I’ll just make do with this.”

For instance, a parent wants to create a literacy game but finds nothing suitable after searching, so they settle for a workbook. Someone wants to clarify abnormal indicators in a health report but, after struggling to understand, decides to ask the doctor next time.

Every “I’ll just make do” represents an unfulfilled service, and every “non-standard” demand signifies an abandoned user.

Secondly, we should replace empty promises with real stories.

Currently, everyone tells users, “You can create any application,” but someone who has never made an app will just be confused. Instead, let’s find 100 real users and share 100 specific stories.

For example, how a mother created a class assignment query tool for all parents the night before school starts. Or how a truck driver made a fuel consumption record sheet for himself.

When users see relatable people solving similar problems, they will naturally want to try it out without needing to be taught what a Coding Agent is.

Finally, we should help users get things done without making them “create applications.”

Most Vibe Coding products start with a blank input box, and most people feel lost when faced with a blank box. They have needs but don’t know how to articulate them.

Perhaps we can reverse the entry point, telling users that if they have an idea, they can create something by speaking, helping them get things done. It’s about providing a service that can solve problems anytime.

Therefore, changing the way we think is crucial for developing Vibe Coding platforms.

Currently, the capabilities of various platforms are generally sufficient; what’s lacking is the ability to tell the story backward. Don’t rush to tell users what they can do; first, understand what problems they have and how service-level products can address them.