Revisiting the Opportunity in Vibe Coding, and Where It Goes

Jiang Wu · 2025-08-15

*Originally published in Chinese on August 15, 2025.*

Vibe coding means building software by describing it to an AI in plain language. Over the past quarter the overall heat has continued. How capital markets and users understand the products has started to lean toward divergence in paths and in functions.

There are two broad types.

1. Assistive tools for professionals

• The core of these products is depth of overall capability, including recognizing and understanding the user's professional scenarios and a deep read of the user's needs.
• On this dimension, such products have high added value, and the users' revenue scale and stickiness are larger.

1. Products for the general public

• The form of these products and their grasp of users lean toward making basic functions universal.
• Besides sitting inside vibe coding products themselves, the core functions of these products are also being added as modules by some AI products.

By market size, the first type gets a higher valuation from capital markets today, its actual revenue growth is also very fast, and it has become nearly a must-win ground for mainstream products. The problem they face next is a systematic choice about depth and breadth of function. Facing more professional users, the added value of the service must be high enough and the depth deep enough to earn a higher premium, and that means the number of such users is limited. These products will very likely end up as infrastructure of cloud service providers. Whether or not cloud providers look deeply involved today, this will become ground they must fight for. So for a while, big cloud providers that don't build it themselves will pay a price to acquire products or teams in the market with good technical accumulation. In this value chain, vibe coding is more than the technology or engineering scenario. It represents resource consumption across the cloud service system, which is the basic premise for cloud providers.

On the other side, the second type, aimed at a wider population, will face two major watersheds.

1. If it takes the community route, the requirements on depth of service and broad universality are not that high. What matters more is playful mechanics that serve fairly niche needs, or scenarios of niche needs being served on the platform. It looks more like a community where everyone contributes ideas and everyone stacks building blocks. This kind of scenario is still rising fast and users' enthusiasm has not faded. It can be understood as a creator economy of templated content. A group of creators provide templates on the platform, and another group of creators or users build their own personalized services on those templates. Or a group of creators create on the basis of content and deliver mature product systems and content to users as services.
2. If it is not a community route and is just a purely mass-market tool, its options face challenges to some extent. One major reason is that what keeps a community product active is not the tool but user content or the community atmosphere, which is already a basic consensus. A purely tool-type product, if not good enough, loses users very fast, and tools are highly replaceable. On this dimension, pure tool products face rather serious problems. Their daily actives and paying users may both still be growing today, but over the long run they will either become a larger open platform, more likely the service-carrying end behind the user's own entry point, which is very easily replaced by cloud services' capability.

Whether deep tool or broad platform, another problem is unavoidable. Suppose in an extreme case that tools and services can be customized at very low cost in the future, and the carrier of a service is no longer a complete tool but one link in the user's value chain. Then they will have many more things to consider.

A very likely situation is that what kills a tool is not another tool but the extension of another capability's boundary. In the past many tool systems fixed the scenario and served it with more specialized capability. In the future the service for some scenarios may be done not by a specialized tool but by a product path that reaches users more easily, and users will give up some professional functions for convenience. A better search engine didn't replace search products. Users' more varied needs were met by a faster path.

Looking at future paths, a more professional vertical service platform and a user platform of community building blocks may be the two options. Whichever of the two it is, we are still at an early stage.

New tool platforms will be born, and a purely community platform remains possible. As for whether it is:

1. A tool growing inside an existing community, or
2. A community growing inside an existing tool,

different product options depend on how the founder thinks today and what they are better at, and neither is right or wrong.

Of course, once the two options above are classified, many products' logic is already in them, and the split will become more and more evident. Is there a middle state? There is, depending on where the user's starting point is.

Home · All articles · Topics · 简体中文