From Vibe Coding to Wish Coding: Is the Product Manager’s Role More Secure or Fragile?

As AI programming tools evolve from Vibe Coding to Wish Coding, the role of product managers is facing a redefinition. Ant Group’s Lingguang App introduces a new concept allowing product managers (PMs) to generate runnable applications using just natural language descriptions. This not only frees up numerous product ideas constrained by development resources but also prompts deep reflections on the core value of PMs. This article analyzes the revolutionary breakthroughs and existing limitations of Wish Coding, revealing the three indispensable judgment skills that PMs must retain in this ’everyone is a developer’ era.

I have been using Cursor to write code for nearly six months. Saying “write code” isn’t entirely accurate—it feels more like “orchestrating code.” I type a few sentences in Cursor describing what I want, and the AI generates a bunch of files. I run it to see the results, and if it’s not right, I describe it again, and it adjusts. After several iterations, a decent prototype emerges.

As a product manager, this experience excites me but also makes me uneasy. The excitement comes from the fact that tasks like writing a PRD and waiting two weeks for development can now yield a demo in an afternoon. The unease stems from the question: if anyone can do this, what is the purpose of a PM?

Yesterday, I encountered the concept of “Wish Coding” proposed by Ant Group’s Lingguang App, which turned my unease into a more concrete concern.

Clarifying the Concept

You have likely heard the term Vibe Coding repeatedly over the past year. Coined by Andrej Karpathy in early 2025, it essentially means telling an AI what features you want in natural language, and the AI writes the code for you—without needing to understand the code itself, as long as it works.

Collins Dictionary selected it as the word of the year for 2025. Over half of the code commits on GitHub are now AI-generated. In the Winter 2025 batch of Y Combinator, a quarter of startups had codebases where 95% of the code was written by AI. These figures are no longer surprising.

What really caught my attention was the new term introduced by the Lingguang App after its upgrade: Wish Coding.

How does it differ from Vibe Coding? I’ll try to explain it in one sentence:

Vibe Coding accelerates “coding,” but you still have to deal with code—setting up IDEs, managing environments, dependencies, and deployment. Wish Coding aims to skip the “code” part entirely—you just need to say what you want, and the system delivers a usable application from generation to deployment.

In PM terms, Vibe Coding improves development efficiency by tenfold but only slightly lowers the entry barrier. Wish Coding aims to eliminate the barrier altogether.

Why PMs Should Take This Seriously

You might think this is just a rebranding of the low-code/no-code story. I initially thought so too. However, after examining Lingguang’s product logic, I changed my perspective.

Traditional low-code platforms, like Jiandaoyun and Mingdao, essentially do “module assembly”—providing you with a bunch of pre-made components to drag and drop. Their ceiling is very low; slightly complex requirements can’t be met.

Wish Coding is different; it runs on large model code generation, theoretically capable of doing things similar to what programmers can write by hand. However, it encapsulates all the “programmer-only” aspects like IDEs, terminals, and deployment. What users see is a dialog box where they state their requirements and, after a while, receive a usable application.

What does this mean? It means that many demands previously stuck at the bottleneck of “having ideas but lacking development resources” suddenly have an outlet.

Anyone who has worked as a PM knows how real this bottleneck is. You might have 20 ideas to validate, but the development team can only fit three into one iteration. The remaining 17 either languish in the backlog or wait until you accumulate enough political capital to push one through.

What if half of those 17 ideas could be turned into demos or even MVPs through Wish Coding?

My Personal Experience

At this point, I must share my own experience, as it illustrates the gap between Vibe Coding and Wish Coding.

I previously used Cursor and Claude Code to create a prototype for an information aggregation tool. From a functionality perspective, it turned out fine—it could scrape multiple information sources, perform basic categorization and filtering, and the frontend was passable. The entire process took about two weekends.

But how much time was spent on “non-functional” tasks?

When setting up the Node.js environment, I faced version conflicts that took an hour to resolve. I spent half a day deliberating on database choices, ultimately opting for SQLite for convenience. I hesitated between React and Vue for the frontend framework. Deploying to the server involved a slew of nginx configuration pitfalls. I even encountered an issue where Claude’s generated code messed up my local file directory structure, costing me two hours to recover.

Each of these issues was unrelated to the product hypothesis I wanted to validate. Yet, they consumed at least 40% of my time.

If there had been a tool that allowed me to bypass all of this and focus solely on “what the feature should look like and what the interaction logic is,” that would be where PMs should truly invest their time.

This is why I believe Wish Coding deserves serious consideration. It addresses not the question of “how to write code faster” but rather “can PMs completely avoid any code-related tasks and directly validate product ideas?”

Caution: Three Major Limitations of Wish Coding

Of course, excitement aside, product people must not overlook constraints. Wish Coding currently has at least three significant issues that must be addressed responsibly.

First, the complexity ceiling.

AI can generate a to-do list application without issue, but creating a SaaS product with login, payment, and real-time collaboration? Not feasible at this stage. A Red Hat analysis aptly states: specifications written by non-technical people are not blueprints but wish lists. AI can help you make wishes, but the quality of the construction depends on the precision of the blueprints.

This indicates that Wish Coding is more suitable for the validation phase rather than the delivery phase. PMs can quickly create demos with it, but don’t expect it to produce a system ready for deployment.

Second, security is a ticking time bomb.

A VeraCode study shows that while large models have made tremendous strides in generating functional code over the past three years, code security has seen little improvement. In early 2026, a vibe-coded application experienced a data leak, exposing 1.5 million API keys and 35,000 user emails. The reason was that the developer (actually a user who had never written a line of code) was unaware that databases need permission configurations.

For PMs, this serves as a practical reminder: using Wish Coding for internal tools, prototype demonstrations, or concept validation is fine, but functionalities involving user data and financial transactions should be left to professional engineers.

Third, debugging is a nightmare.

A saying on Reddit sums it up well: 20 minutes to generate 20,000 lines of code, two years to debug. You can’t understand AI-generated code, and if a bug arises, you don’t know where to start. MIT research also indicates that AI-generated code appears very “polished,” making errors even harder to detect.

This means that the lifespan of things generated by Wish Coding is destined to be short. You can use it as a one-time prototype, but don’t expect it to sustain iterative evolution.

The Real Opportunity for PMs

After discussing the risks, let’s talk about how I believe PMs should view this wave of change.

Wish Coding is not replacing product managers; it is redefining the core competencies of PMs.

In recent years, much of a PM’s daily work has been about “translation”—translating business requirements into a language developers can understand, writing PRDs, and creating prototypes. These tasks are not unimportant, but their value is rapidly diminishing. As AI becomes increasingly capable of directly understanding natural language descriptions of requirements, the intermediary translation layer is becoming thinner.

So, what can’t AI replace?

Judgment.

Specifically, there are three types of judgment:

Judgment on what to do. In a world where the cost of “building applications” approaches zero, what is scarce is not capacity but direction. Which problems should be solved for users? Is this problem worth solving? Is anyone in the market already addressing it? These judgments require deep understanding of users, continuous market observation, and insight into business logic. These are things that cannot be replaced by a few prompts.

Judgment on what not to do. When everyone can instantly create an app, restraint becomes more valuable than execution. Knowing which features to cut and which to keep among a bunch of seemingly good options, and knowing when to simplify, is a professional skill in itself.

Judgment on defining standards. AI-generated outputs may be usable, but there’s a vast difference between “usable” and “well-designed.” How do you refine interaction details? How do you handle exceptional processes? Have edge cases been considered? These are all within the PM’s professional domain and are the true dividing line for product quality.

A Practical Suggestion

Finally, let’s discuss something practical. If you are a PM, I suggest you start doing one thing now: Incorporate Wish Coding-like tools into your daily workflow, but only for the validation phase.

Next time you have a product idea to communicate with your boss or stakeholders, don’t spend three days writing a PRD. Use Lingguang or Replit to create a runnable demo in half a day. Use a real interactive prototype instead of PPT and Axure wireframes for communication.

This approach has two benefits. First, it speeds up validation by an order of magnitude, allowing many unfeasible ideas to be eliminated during the demo phase, saving development resources. Second, it establishes a new perception within the team: this PM can not only create prototypes and write documents but can also turn ideas into operational products.

But remember the bottom line: the outputs from Wish Coding are for validating ideas, not for going live. After validation, the technical plan still needs to be written, and code reviews must still be conducted. Start with wishes, but finish with engineering.

This is likely the healthiest relationship between a product manager and AI programming tools in 2026.