The Shift in AI Product Management

The battlefield for AI product managers is shifting from conference rooms to code editors! As teams argue late into the night over the interaction details of ‘users interrupting AI speech’, someone creates a runnable demo in just half an hour using Cursor. This is the explosive Vibe Coding revolution in Silicon Valley. It not only changes the way PRDs are written but also allows product managers to validate model behavior, quickly iterate solutions, and even build their own toolkits. This article unveils the new paradigm of ‘describing requirements to generate code’ and how it reshapes the logic of product development and the core competencies of PMs in the AI era.

A Friday Night Meeting Without Winners

Let me share a real experience from last month.

On a Friday night, only three of us remained in the conference room: the frontend developer, the algorithm engineer, and myself. We had been arguing for an hour and a half over the interaction details of an AI dialogue product regarding ‘users interrupting the model mid-sentence’.

I said: “The model’s speech should stop the moment the user speaks.” Lao Li countered: “That would cause issues with token billing since the model is still generating.” The frontend developer added: “We can’t capture such real-time events; the backend needs to push that information.” I mentioned: “Other products can do it; I’ve used the voice mode of ChatGPT.” The algorithm engineer replied: “I don’t know how they achieve that; our architecture is different.”

We were stuck. I knew that continuing to argue would lead nowhere—because I couldn’t articulate ’exactly what should be done’, and they couldn’t explain ‘why it couldn’t be done’. We were all firing blanks in our own languages.

On my way home that night, I opened Cursor and described the interaction requirement in natural language. Half an hour later, I had a rough but runnable demo in my hands. It wasn’t perfect, but it clearly showed me how this could be implemented on the frontend, what events the backend needed to provide, and where the token billing issue occurred in the code.

The next morning’s meeting ended in thirty minutes.

This is what I want to discuss with you—Vibe Coding is becoming a new watershed among AI product managers.

Not because it turns product managers into engineers, but because it transforms product managers into those who can ‘bring their ideas to life’. The difference between these two is far greater than you might think.

Understanding Vibe Coding

Let’s clarify the term ‘Vibe Coding’ to prevent it from becoming another overused concept.

On February 2, 2025, Andrej Karpathy, former AI director at Tesla and a founding member of OpenAI, tweeted:

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

This tweet exploded overnight in Silicon Valley. Various media outlets and podcasts began using the term. While the popularity of a new term often comes from hype, vibe coding has gained traction because it truly describes a new way of working:

You no longer write code. You describe what you want. AI writes the code. You see the results and describe what needs to be changed. AI modifies the code until it runs.

Doesn’t that sound like what product managers do?

Yes, vibe coding is essentially more akin to product behavior than engineering behavior. It requires you to clearly describe requirements, recognize correctness, and make choices among various candidates—these are all core skills of a product manager.

Let me distinguish it from a few easily confused concepts:

• It is not “product managers learning Python to write scripts”. That was the case in 2015.
• It is not “using ChatGPT to help you write a few lines of SQL”. That was 2023.
• It is not “dragging and dropping a form on a low-code platform”. That pertains to enterprise IT.

It is: You sit down with an AI editor like Cursor, Claude Code, or Codex, and say, ‘I want a page that allows users to upload resumes, extracts educational background and work experience using a large model, and finally generates a radar chart’, and it actually gives you a runnable product.

After it runs, you say, ‘The color is ugly; change the radar chart to a timeline’, and it continues to modify. You say, ‘Add a button to export as PDF’, and it continues to change. You say, ‘I want to connect to the internal talent pool API’, it asks for the documentation, and you provide it, and it connects.

Throughout the process, you may not have seen a single line of code, but you created something usable.

Currently, mainstream vibe coding tools can be broadly divided into two categories:

1. AI Editors: More suitable for local development, targeting those with some technical knowledge—Cursor (the first to gain popularity), Claude Code (Anthropic’s own CLI), Windsurf (formerly Codeium before being acquired by Cognition), Cline, etc.
2. Web-based Generators: Usable directly in the browser, accessible even to those with no coding knowledge—v0 (from Vercel, specifically for frontend components), Bolt.new (from StackBlitz, capable of full-stack development), Lovable (a Swedish team focusing on rapid development from requirements to demos), Replit Agent.

Both types of tools are undergoing significant changes, but they point in the same direction: to directly produce runnable products from ’thinking clearly + describing clearly’.

Why AI Product Managers Need This Skill More Than Others

You might ask: Product managers who can code have always existed; many senior PMs in search, e-commerce, and social fields can code. Why single out AI PMs?

Because AI products possess three fundamentally different characteristics from traditional products, making the ability to ‘bring something to life’ a necessity rather than just a bonus.

1. Unpredictable model behavior; PRDs cannot clarify everything.

When you create a form page, the requirements are clear: what the user inputs, which button to click, and which page to jump to. You finish the prototype, and the engineers implement it accordingly.

But what about a feature like ‘AI helping users revise resumes’? You write, ‘The model should make the resume more professional.’ How do you define ‘professional’? You write, ‘Output should not exceed 500 words.’ What if the model has a 30% chance of outputting 600 words? You write, ‘The tone should be friendly but not cheesy.’ Where is the boundary for ‘cheesy’?

These questions cannot be clearly articulated by a product manager sitting at their desk writing documents, because the answers lie in ‘seeing what happens when the model actually runs’. If you don’t run it, your PRD is just a guess.

2. High cost of trial and error, but many iterations are necessary.

The effectiveness of AI features often depends on very fine details: how to write prompts, how much context to provide, which model to use, what temperature to set, and whether to add a reasoning chain. You cannot understand these things just by thinking; you need to run them on real data.

If you have to schedule an engineer’s sprint for each trial and error, taking a week to get a version, your product won’t iterate for three months.

If you can run it yourself, you can think of a new prompt in the afternoon, see results on 50 real user data points by the evening, and go to the engineer the next morning with conclusions for discussion on launch. Your iteration speed increases by an order of magnitude.

3. Short competitive windows; being a step behind means losing out for a year.

The pace in the AI field is such that if you see an opportunity in early 2024, you must have a product launched within six months, or someone else will take the position. Think about the AI tools that have emerged from last year to this year—translation tools, voice generation, PPT creation, interview simulations—what team hasn’t rushed to create a demo to secure funding and then quickly iterated to launch?

Your competitors might be a small team of three, where the PM can use Cursor to write the frontend, and the boss/engineer uses Claude Code at home to write the backend. They can launch a new feature in a week while your company’s PRD is still under review, and they have already digested the second round of user feedback.

These three characteristics combined mean that the role of AI PM is no longer just about ’talking’. It requires you to think clearly and bring ideas to life. Just thinking won’t keep up with the pace; just running will produce the wrong things. You need both abilities.

Advantages of AI PMs Who Can Vibe Code

Here are six advantages that I’ve personally experienced over the past year using Cursor and Claude Code. I will try to avoid vague statements and provide specific scenarios.

1. Run a demo before writing the PRD, directly elevating document quality.

In the past, writing a PRD for an AI feature involved a lot of agonizing over:

• Is the model’s intent recognition accurate? If I write ‘recognize user inquiry intent’, an 80% accuracy rate versus a 95% accuracy rate corresponds to completely different product forms.
• Is this interaction smooth? In my flowchart, ‘user input → model response → user follow-up’, but running it might reveal that context is lost during follow-up.
• How do we handle edge cases? If a user uploads a 50MB PDF and the model times out, how do we display that on the frontend?

In the past, I could only write ’to be reviewed’ or ’to be determined after development’, and then developers would complain when they received the PRD—because I had passed all the uncertainties onto them.

After learning vibe coding, I spend two hours running a rough prototype before writing the PRD. What I gain from those two hours includes:

• I see firsthand what the model’s accuracy is on 30 real use cases, and I can directly write in the PRD, ‘Target accuracy is 90%, current baseline is 73%, need to invest in prompt engineering or fine-tuning.’
• I walk through the interaction myself and realize that in the follow-up scenario, I need to include the previous input in the context, so I clearly outline how the context should be assembled in the PRD.
• I run into the error for the 50MB PDF and can directly write in the PRD, ‘File size limit is 20MB; the prompt message when exceeded is XXX.’

The PRD transforms from a ‘question list’ into an ‘answer list’. The review time shrinks from two hours to forty minutes.

2. When discussing with engineers, you have confidence, and they find it easier.

I used to dread discussing plans with senior engineers. It wasn’t because I was afraid they would challenge me, but because I feared their casual remarks like ’this can’t be done’ or ’this will take two weeks’, and I had no way to judge their correctness.

PMs who can’t code usually respond in two ways: one is ‘I’ll ask someone else’—passing the ball to a superior or another engineer, which diminishes your professionalism. The other is ‘Okay’—accepting the engineer’s judgment directly, but if they are wrong, the entire product timeline gets delayed.

After learning vibe coding, I gained a third option: I can run it myself and see whether it truly can’t be done.

Recently, I proposed a requirement: ‘Allow the model to output long documents in a streaming manner and support users interrupting to regenerate.’ Our engineer said it would require a complete refactor of the streaming pipeline, taking at least two weeks.

I didn’t argue on the spot; instead, I went back and crudely implemented this feature using Claude Code in a demo repository—not production-ready, but it worked. The next day, I shared that repository with the engineer and said, ‘This is a version I ran through; let’s see what changes are needed to merge it with our existing code.’

After reviewing it, the engineer revised his estimate to ‘we can do it in five days’.

This isn’t about proving the engineer was slacking—he wasn’t; he just saw risks in a complex architecture he was familiar with. But when you provide him with a reference that has already run smoothly in a simplified scenario, his estimation of the workload becomes accurate because he sees a concrete implementation rather than an abstract requirement.

This improvement in communication efficiency is mutual. Engineers also prefer collaborating with PMs who can run code because they don’t have to start explaining from ‘what is a token’ every time.

3. After user interviews, provide a prototype on the spot that leaves users amazed.

This is my favorite advantage.

The traditional user research process involves: interviews → writing reports → internal meetings → revising PRDs → scheduling development → waiting for demos → re-inviting users for validation. This cycle takes at least three weeks.

A PM who can vibe code can do this: interview five target users in the morning, then use Bolt or Lovable to crudely assemble a frontend prototype of the core interaction in the afternoon—no backend needed, just run it with mock data. The next afternoon, invite two of those users back to test the prototype.

You don’t need to wait for a sprint or schedule development. Your ‘hypothesis → validation’ cycle shrinks from three weeks to two days.

More importantly, when users face something clickable, the feedback they provide is completely different from when they see a static image. When you show them a Figma prototype, they might say, ‘Looks good, seems smooth’, but when you give them a runnable demo, they immediately say, ‘Why is this button so hidden? I searched for it for ages.’

This feedback is invaluable. You receive it before the PRD enters development, meaning you reduce 80% of rework.

4. Build internal tools yourself, no longer relying on others or waiting.

AI product managers spend a significant portion of their time dealing with ‘data’: labeling data, reviewing cases, conducting evaluations, checking bad cases, and statistical distributions…

If you have to ask engineers or the data team for help building tools for every task, you will always be a second-class citizen. PMs who can vibe code build their own.

I have built at least the following internal tools:

• A case labeling page: pulling online bad cases for team members to tag, comment, and filter by dimensions.
• A prompt comparison tester: inputting prompt A on the left and prompt B on the right, running the same batch of data to see output differences.
• A user feedback aggregation panel: feeding feedback from the App Store, customer service tickets, and surveys to the model for automatic thematic categorization.
• A competitor monitoring bot: crawling updates and social media from several competitors daily, generating summaries sent to my own Feishu group.

If these tools went through the formal development process, each would take at least two weeks, and why should the engineering team prioritize your ‘personal tool requests’?

I build them myself; each tool takes at most one or two evenings. They may be rough, but they are functional. Functional is enough because their target users are only myself and a few team members; they don’t need to be as solid as ToB products.

The compound effect of this is particularly staggering. After a year, you have a dozen more tools than your colleagues, and the efficiency gap in your work is no longer just due to vibe coding itself, but because you have your own ‘small toolkit army’.

5. Evaluate third-party technical solutions without being swayed by ‘sounds impressive’.

In the AI field, new models, frameworks, APIs, and agent platforms emerge every month. Vendors line up to pitch, and each claims to have ‘95% accuracy’, ‘industry-leading’, or ‘proprietary technology’.

PMs who can’t code can only watch their demos, see their cherry-picked showcases, and make selections based on gut feelings.

PMs who can vibe code directly open their API documentation, write a test script in half an hour, feed in 100 real samples from their business, and run actual accuracy comparisons. They can then spend another half hour integrating the second vendor’s API for comparison.

The pitfalls this action can help you avoid are astonishing. I once experienced this: a vendor’s model performed exceptionally well during a demo, but before signing the contract, I ran it myself and found that in our Chinese financial context, the accuracy was only 60%. This difference was enough for us to switch vendors, saving tens of thousands in annual fees.

When you can ‘verify hands-on’, you are no longer the one being sold to; you are the one conducting the evaluation.

6. Improved judgment in hiring and managing, knowing what engineers are doing.

Finally, this point is less direct but becomes increasingly important as you move up the ranks.

AI product managers will eventually need to lead teams. You will interview engineers, assess performance, decide who is responsible for which project, and evaluate the merits of technical solutions.

PMs who can’t code will become increasingly vague at this level—when you hear an engineer say they worked on ‘model quantization acceleration’ this week, you won’t know if that was a 30-minute task or a three-week endeavor. When you hear a candidate say they are familiar with ‘RAG’, you won’t know if they have genuinely built something or just read articles.

PMs who can vibe code don’t need to understand as deeply as engineers, but you can avoid being misled. If you’ve run a simple RAG yourself, you will know which points are genuinely difficult and which are publicly available tutorials that can be copied. If you’ve personally integrated an LLM API, you will have a rough idea of how long an iteration task will take.

This judgment is essential for a leader. It doesn’t relate to whether you can write production-level code; it relates to whether you have personally engaged with these concepts.

A Word of Caution: Vibe Coding Is Not a Panacea

While I have praised vibe coding, I must also clarify its limitations. Otherwise, you might finish reading this article feeling overly confident and end up facing significant setbacks.

1. A runnable demo does not equal a deployable product.

The code produced through vibe coding often falls short of quality standards. Security vulnerabilities, performance bottlenecks, edge case handling, concurrency, data persistence, monitoring, and alerts—these issues will not be caught without professional engineers reviewing them, leading to serious problems.

I once had an internal tool I built used frequently by colleagues, and someone accidentally connected it to the production database, nearly causing an incident. Professional engineers would catch such issues during code reviews, but vibe coding does not.

So your outputs have their place: prototypes, demos, internal tools, PoCs, evaluation scripts, and personal tools—these are the main battlegrounds for vibe coding. Production-level code for real users must still be handled by the engineering team; they will likely rewrite it, which is reasonable.

2. You might develop a sense of ‘I can do anything’.

In the early days of using Cursor, I often felt I could tackle anything—ask me to create a recommendation system? I can do it. Ask me to build a payment gateway? I can do it.

Until one day, I actually tried to set up a simplified payment process, and after running it, I excitedly showed it to a friend on the payment team. After five minutes of review, he pointed out seven security vulnerabilities, two of which could directly lead to SQL injection and empty the database.

Vibe coding makes it easy to create something that ’looks runnable’, but there is a significant gap between ’looks runnable’ and ‘actually runnable’ that involves engineering quality, security awareness, and understanding business boundaries. These are things vibe coding cannot provide.

3. You might forget to communicate well with engineers.

After learning to code, I went through a phase where I even started bypassing engineers—‘I can do it myself; I’ll just get it done first and then discuss.’

This is wrong. Your role is not to replace engineers but to collaborate better with them. No matter how good your code is, it remains a prototype; the production-ready code will still be written by the engineering team. If you strain your relationship with them, no amount of demos will help.

The correct approach is to run it yourself and use it as a communication tool, rather than presenting it as ‘I’ve completed this; now you just need to replicate it’.

4. You might think you understand technology.

You don’t. You are merely using a very smart AI to help you write code.

True technical understanding requires you to debug, identify issues from a stack trace, weigh different architectural solutions, and anticipate system failures under load. Vibe coding cannot provide this; you need to accumulate it over time by writing code line by line and encountering issues repeatedly.

So please remain humble. You have merely gained an additional skill, not transformed into another profession.

Methodology: 30 Days to Master Vibe Coding

After discussing so much, here’s a practical method you can directly follow.

Starting Phase: Days 1 - 7, Get the Tools Running

• Day 1: Choose a tool, register, and run the first example.

  • If you have no coding experience, I recommend starting with Lovable or Bolt.new, which can be used directly in the browser without any setup costs. If you have some knowledge (like having installed Python or used git), go for Cursor or Claude Code, which have a higher ceiling and are more suitable for long-term use.
  • The goal for the first day is simple: get any tool to produce a Hello World-level webpage. A page that displays ‘Hello’ is sufficient. The focus is on resolving account, subscription, and environment setup issues all at once.

• Days 2 - 3: Complete a ‘real but simplified’ small project.

  • Don’t start with your company’s product. Choose something you are personally interested in. For example:
    • A page that shows the weather for the next three days in your city (practicing API calls)
    • A tool that summarizes an English article you input into Chinese (practicing LLM calls)
    • A page that sorts your to-do list by priority (practicing frontend interactions)
  • Each project should take two to three evenings to complete. This step is about building confidence, making you believe ‘I can also create something runnable’.

• Days 4 - 7: Deliberate practice on ‘how to describe requirements’.

  • Success in vibe coding depends 70% on your ability to describe requirements. With the same tool, person A can articulate their needs in three sentences, while person B might take fifty sentences and still fail to clarify—resulting in vastly different outcomes.
  • Spend an hour each day this week practicing breaking down a requirement into language that AI can understand. The mindset is:
    • Start with the overall: ‘I want to create an X for Y.’
    • Then specify inputs and outputs: ‘User inputs A and receives B.’
    • Next, outline key constraints: ‘Must support Z, and not include W.’
    • Finally, describe appearance: ‘Style similar to Notion, use light colors.’
  • Well-written requirement descriptions are themselves good PRDs. This skill is a valuable byproduct of vibe coding.

Advanced Phase: Days 8 - 21, Start Applying at Work

• Days 8 - 14: Redo a recent PRD using Vibe Coding.

  • Choose a feature you recently wrote, which has already been reviewed or developed. Don’t pick something you haven’t done before, as you need a reference.
  • Recreate this feature using vibe coding, only running a core interaction version. For example, if you previously wrote a PRD for ‘AI resume optimization’, create a minimal version that allows users to upload resumes, call the model, and output optimization suggestions.
  • After completing it, do two things:
    1. Compare it with your previous PRD and note any points where ‘if I had run this demo earlier, I would have written it differently’. List these points as the direct benefits vibe coding provides.
    2. Show this demo to the engineers who worked on that feature and ask them: ‘If I had given you this at the time, how much time would we have saved?’ Listen to their response. This will determine your motivation to continue investing in this skill.

• Days 15 - 21: Build an internal tool for the team.

  • Choose a task that everyone in your team finds ‘annoying but no one has time to tackle’. For example:
    • Pulling online bad cases weekly and categorizing them
    • Summarizing customer feedback by theme
    • Tracking updates from several competitors
  • Use vibe coding to automate or toolify this task and share it with the team. Don’t aim for perfection; rough is fine, as long as it’s useful.
  • The goal is to establish a sense of ’the tools I build can solve real problems’ and to let the team see this capability. Both psychological benefits are crucial.

Practical Phase: Days 22 - 30, Use It in a Real Project

Choose a feature you will lead in the next sprint and apply vibe coding from start to finish:

• Before the PRD: Run a rough prototype to validate feasibility, then decide how to write the PRD.
• During PRD review: Use your prototype demo to illustrate key interactions in the review meeting.
• During development: Continue iterating on the prototype to sync details with engineers.
• During testing: Write some automated test scripts or case evaluation tools using vibe coding.
• After launch: Build a monitoring dashboard to track core metrics.

After completing a full sprint, you will have integrated this ability into your workflow. It will no longer be an ‘additional skill’ but rather a part of ‘how I do product management’.

Long-term Mindset: Three Key Sentences to Remember

By now, you have entered the realm of vibe coding; what remains is the long-term mindset. Here are three key sentences I’ve summarized:

1. Those who can describe clearly can harness AI.

   • Regardless of how tools evolve, the ability to ‘clearly articulate what I want’ will always be your core competency. Each time you write a prompt, you are exercising this muscle.

2. Running something is just the starting point, not the endpoint.

   • Successfully running a demo is merely your ticket in. True product capability is reflected in whether you can judge its quality, think clearly about how to improve it, and communicate effectively with engineers about how to create a production-level version.

3. Do not pretend to be an engineer.

   • You are a product manager. Your stage is further forward—understanding users, defining value, driving implementation. Vibe coding is your new tool, not your new identity.

Conclusion: The Times Have Changed, and So Have the Moats

I started as a product manager in 2014. Over twelve years, the criteria for ‘what makes a valuable PM’ have changed several times.

Initially, it was about writing PRDs because most people did it poorly. Then it shifted to understanding data, where PMs who could run SQL queries were more valued than those who relied solely on intuition. Later, it became about having business acumen, where those who could link features to revenue advanced faster.

Now it’s the era of vibe coding.

I’m not saying PMs who can’t vibe code will be immediately eliminated—most traditional PM work styles will still be applicable for several years in many companies. But look at the fastest-growing AI companies and those products that can go from 0 to 1 million users in three months; the product managers in those teams are almost uniformly already running code themselves.

This is the true meaning of ‘moat’. It’s not that you won’t survive without a certain skill; it’s that when the next wave of opportunities arises, whether you can seize them depends on whether you have prepared today.

The ability to vibe code is not hard to acquire, but you need to start practicing today. Your future self will thank you for downloading Cursor tonight.

Good night, and go run your first demo!