Why I Wrote This Article

In the past two months, I have collected nearly forty articles about Vibe Coding.

Some say it’s the “second spring for product managers,” while others claim it’s the “grave digger for programmers.” Some have built a SaaS tool in three days and started charging for it, while others created a system that crashed upon launch and then wrote a reflection post. After reading all these articles, I found myself in a strange confusion—each article seemed reasonable, but together they contradicted each other.

The excited articles made me feel that if I didn’t get started immediately, I would be left behind by the times; the pessimistic articles made me think this was just another bubble. But neither emotion helped me clarify one thing: as a product manager, how should I view this, how should I use it, and what should I use it for?

This article is neither a review nor a tutorial. It is a record of my attempt to establish a judgment framework after digesting a lot of information. If you are also a product manager or someone equally confused about this topic, I hope this article can provide you with a different perspective—not to make you more excited or more pessimistic, but to help you think a little clearer.

What Are We Really Debating: A Discussion Burdened by Naming Confusion

First, an observation: most debates about Vibe Coding are not discussing the same thing.

This is not to say who is right or wrong, but rather that—the same term is given completely different meanings by people from different backgrounds. When the foundational definitions of a debate are not aligned, all confrontations are just noise.

I have summarized several common understandings into the following diagram:

For product managers, Vibe Coding means “I can finally turn my ideas into clickable things quickly”; for programmers, it means “a reckless development method that incurs technical debt.” These two groups are not even on the same discussion channel, but they are using the same term, so the debate never ends.

There’s an even deeper confusion: Vibe Coding and AI Coding are often used interchangeably, but they are not the same thing.

Once this distinction is clarified, many debates automatically dissolve. Programmers criticize Vibe Coding as “unmaintainable and lacking architecture,” which is a valid criticism—but it is valid only if Vibe Coding is evaluated as an engineering practice. The problem is, for a product manager using Vibe Coding for prototyping, “maintainability” is not their optimization goal.

Evaluating a product manager’s tool by engineering standards is like judging instant noodles by Michelin standards—it may not be good enough, but that’s not the point.

What Vibe Coding Truly Changes from the Product Manager’s Perspective

Having clarified the concepts, let’s discuss the essence.

Many articles discussing the impact of Vibe Coding on product managers mention: PMs can now prototype themselves, PMs can create internal tools, and PMs will deepen their technical understanding. While all these points are valid, I believe they do not touch on the core layer.

The most fundamental change is: the validation rhythm has changed.

Specifically—the greatest value of Vibe Coding is not what you can do, but how quickly you can see your mistakes.

This may sound strange, so let me explain.

The traditional product validation path looks something like this:

After Vibe Coding, the path can change to:

Note that both paths lead to the same endpoint—“discovering the direction was wrong.” But the time cost and sunk cost are completely different.

What does this mean? It means you can afford to make bolder mistakes because the cost of making mistakes has decreased. A direction that previously required three weeks of deliberation to propose can now be validated in two days. This is not just an efficiency improvement; it is a fundamental change in product decision-making.

I call this “gaining the ability to quickly iterate.” This is much more precise and important than saying “PMs can write code.” Whether a PM can write code has never been the key issue; what matters is whether they can quickly obtain “sufficiently realistic errors.”

An Overlooked Issue: Your Business Understanding Determines the Upper Limit of Vibe Coding

Having discussed what Vibe Coding can achieve, let’s address a more uncomfortable question—why might it not work as well in your hands?

Most discussions about the limitations of Vibe Coding focus on the tools: the quality of AI-generated code is unstable, complex systems are hard to maintain, and there are security risks… all of these are real issues, but they represent the “ceiling of the tools.” There is another ceiling that product managers should pay attention to, which comes from the users themselves.

AI can turn your vague ideas into runnable code, but if your business understanding is itself vague, AI merely amplifies and materializes that vagueness.

For example, suppose you are creating a lead management tool for a sales team. You tell AI: “Help me create a system to manage sales leads, with status transitions, follow-up records, and priority sorting.” AI will generate a seemingly complete system. But there are several questions that AI cannot answer:

• How is the “status” of a sales lead defined? In your company’s business process, are “in follow-up” and “intention clarified” two statuses or the same status?
• What should the “priority” be based on? Customer size? Last contact time? Or the subjective judgment of the sales supervisor?
• Should leads from different salespeople be visible to each other? Or should they only be visible to themselves?

These questions are business logic issues, not technical issues. AI does not know how your company operates, nor does it understand the real pain points of your sales team. The prompts you give to AI are essentially an externalization of your business understanding. The deeper your understanding, the more precise your prompts will be, and the closer the output will be to what is truly needed; the shallower your understanding, the more vague your prompts, and the output will resemble a “nice-looking but useless” demo.

Here’s a counterintuitive conclusion: Vibe Coding does not lower the requirements for product thinking; it raises them—because it leaves you nowhere to hide.

Previously, PMs could rely on a well-written requirements document to cover up vague business understanding. A document that is logical, structured, and data-driven looks professional—but specific business details will be questioned during implementation by developers and tested by QA, which objectively fills in the gaps in business understanding.

Vibe Coding removes these intermediate steps. Your thinking directly maps to the product, and no one is there to cover for you. The amount you understand directly translates to what you can produce. This is the fundamental reason why Vibe Coding demands higher product thinking, not lower.

The Divide Between “AI Dependents” and “AI Drivers” Also Applies to PMs

A study by Anthropic on AI-assisted programming revealed a noteworthy finding: developers using the same tools but with different approaches have completely different growth trajectories. Those who actively use AI to learn, iterate, and experiment see their abilities continuously grow; those who treat AI as an “outsourcing object,” only caring about results without considering the process, become increasingly dependent on the tool while their independent judgment declines.

This conclusion has been interpreted as a warning for programmers, but I believe it applies equally to product managers—perhaps even more so, because PMs are not primarily responsible for writing code, making this “dependency trap” harder to detect.

In the PM community, I have observed two distinctly different approaches to using Vibe Coding:

First Type: Hands-off Manager
Idea for demand → Throw to AI → Wait for output → Use if it seems okay → Throw to AI again
This type of PM uses Vibe Coding in a way that mirrors their previous method of tossing requirements to developers. The executor has changed, but their depth of thought remains the same. They use whatever AI provides without knowing where to start when problems arise, and the quality of the final output heavily relies on AI’s “luck.”

Second Type: Proactive Calibrator
Idea for demand → First clarify core logic → Give AI a structured description → Receive output → Actively find problems → Correct assumptions → Iterate again
This type of PM uses AI as a tool to quickly execute their thoughts, remaining the primary thinker. They use Vibe Coding not to avoid thinking but to accelerate the realization and testing of their thoughts.

The key to distinguishing these two approaches is not “how many times you used AI,” but rather “after each use, did you understand the problem better than before?”

Tools will evolve, but whether your understanding of the problem deepens after each use is something you decide for yourself; AI cannot help you with that.

When to Use and When to Stop: Draw a Line for Yourself

At this point, many might ask: What scenarios are suitable for Vibe Coding, and which are not?

Most articles respond by listing a scenario checklist: suitable for prototyping, suitable for internal tools, not suitable for large systems… While this checklist has reference value, it can be cumbersome to use because real situations are often ambiguous and mixed.

I prefer to provide a judgment framework rather than a checklist. The core logic has only two dimensions:

Dimension One: Validation Cost vs Implementation Cost
When the “validation cost” (the time and resources needed to determine if the direction is correct) far exceeds the “implementation cost” (the resources needed to create it), the value of Vibe Coding is maximized.
Because Vibe Coding essentially compresses validation costs. If validation is already inexpensive, its contribution is limited; if validation costs are high, its involvement can significantly change decision efficiency.

Dimension Two: Maintenance Cost vs Generation Cost
When the “maintenance cost” of a system (the ongoing investment required for iterations, fixes, and expansions after going live) far exceeds the “generation cost” (the initial investment needed to create it), the risks of Vibe Coding are highest.
Because the code generated by Vibe Coding typically has defects in “maintainability,” which are inconsequential in one-time validation scenarios but can accumulate into serious technical debt in long-term operational systems.

Using this framework, let’s evaluate a few common scenarios:

Scenario One: Creating a clickable prototype for a new feature direction
Validation Cost/Implementation Cost: High (it’s difficult to judge if the direction is correct, but it’s quick to create)
Maintenance Cost/Generation Cost: Low (prototypes don’t require maintenance)
→ Strongly recommended to use Vibe Coding

Scenario Two: Building an internal lead tracking table for the sales team
Validation Cost/Implementation Cost: Medium (the needs are relatively clear)
Maintenance Cost/Generation Cost: Medium (internal tools require iterations, but they are not core systems)
→ Can use, but need to assess who will be responsible for subsequent maintenance

Scenario Three: Developing an e-commerce feature that integrates with a payment system
Validation Cost/Implementation Cost: Not high (the needs are relatively clear)
Maintenance Cost/Generation Cost: Extremely high (involves security, compliance, and high concurrency)
→ Do not use Vibe Coding; follow formal engineering processes

The essence of this framework is to help you think clearly about the purpose of using Vibe Coding before diving in. If the purpose is validation, it’s a great tool; if the purpose is to deliver a long-term operational system, it will likely lead you into pitfalls.

Tools Will Evolve, but Judgment Will Not Automatically Grow

I rarely write sentences like “the era has arrived” in articles, not because I don’t believe in the power of AI, but because such sentences excite readers without providing actionable insights.

So at the end of this article, I want to say something more straightforward:

Tools are evolving, and the speed of evolution is faster than we expected. Today, Vibe Coding has many limitations, some of which will disappear in six months, and more will disappear in a year. A significant portion of the conclusions in articles discussing the limitations of AI programming will have a shelf life of no more than eighteen months.

However, one thing the evolution of tools cannot solve is your own judgment.

Vibe Coding can help you “turn ideas into clickable things” faster, but it cannot help you judge:

1. Is this idea worth pursuing?
2. To what extent is sufficient, and when do I stop investing?
3. Is the user’s real problem the one you think it is?

These three questions are the core reasons for the existence of the product manager role, and they are areas where no tool will replace your thinking.

I sometimes feel that the emergence of Vibe Coding provides a great “mirror” opportunity for product managers—it amplifies your business understanding while exposing your cognitive gaps. The result in the mirror is your own.

My advice is simple: don’t focus all your energy on “learning to use tools”; also spend time on “deepening your business understanding.” The former will become easier as tools improve; the latter will never happen automatically because business understanding requires your proactive effort to build.

This is not a matter of “embracing AI” or “being wary of AI”; it’s a question of what kind of product manager you want to become. Tools provide you with the ability to act faster, but the direction of that action is always for you to judge.