Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Vibe coding means building software by describing what you want to an AI tool in plain language and iterating on what it produces, often without writing much code yourself. For PMs it is a fast way to make ideas concrete: clickable prototypes, data explorations, small internal tools, and AI feature experiments with real model calls. It is excellent for learning and communicating, and not a substitute for engineering when reliability, security and scale matter.
How to approach it
Define the term, give concrete PM uses, describe a sensible workflow, and set boundaries.
A strong answer
Definition. The term was coined by Andrej Karpathy in February 2025 and named Collins Dictionary's word of the year for 2025, defined as "the use of artificial intelligence prompted by natural language to write computer code" (Collins). In Karpathy's original sense you "forget that the code even exists", which he described as fine for throwaway weekend projects. Simon Willison's distinction is the useful one for a PM: if an LLM wrote the code and you then reviewed and tested it, "that's not vibe coding" (March 2025). Prototypes for discovery can be vibe-coded; anything a customer or colleague relies on cannot.
In practice: instead of writing code line by line, you describe the behaviour you want ("a page where I paste a customer email and get a suggested reply with the relevant policy quoted"), let an AI coding tool or app builder generate it, run it, and iterate by describing changes. The skill lies in describing clearly, checking results and steering.
Good uses for PMs.
| Use | Example |
|---|---|
| Prototypes for discovery | A clickable flow to test with five users before engineering commits |
| AI feature experiments | Real model calls with real prompts to see whether the idea works at all |
| Evaluation notebooks | Run 50 examples through two prompts and compare pass rates |
| Data exploration | Quick analysis of exported tickets or usage data |
| Internal tools | Small utilities for the team, with low stakes |
| Communication | Showing engineers and leaders what you mean instead of describing it |
A sensible workflow.
- Write down the user, job and success criteria first.
- Start with the smallest version that tests the core idea.
- Use real or realistic sample data, never sensitive customer data in unapproved tools.
- Check the output: run test cases, not just one happy example.
- Keep notes on what you learned: what worked, what failed, what surprised you.
Boundaries.
- Not production code. Generated code may have security flaws, poor error handling, and no tests. Hand it to engineering as a reference, not as a deliverable.
- Data and privacy. Do not paste customer data or credentials into tools without approval.
- Understanding. If you cannot explain what the prototype does, you cannot judge whether it works.
Why it matters for a PM. PMs who can make ideas concrete in an afternoon test more ideas, communicate better, and understand model behaviour first-hand. Some employers now test it: Canva, for example, tells engineering candidates it expects them to use AI tools in technical interviews (Canva engineering blog, June 2025). Policies differ, so ask the recruiter what a PM loop includes and which tools are allowed.
Know the two failure modes. Speed can be an illusion: a randomised trial with experienced developers found AI tools made tasks take 19% longer even though they expected a 20% speed-up (METR, 2025). And generated apps can ship real holes: a 2025 vulnerability record described AI-built sites whose database rules let unauthenticated users read or write tables (CVE-2025-48757, disputed by the vendor). A prototype that touches real data needs the same review as any other code.
What interviewers probe next
"What's the biggest risk of PMs vibe coding?" Mistaking a working demo for a reliable product, and leaking sensitive data into tools.
"Should every PM learn this?" Yes, at least enough to prototype AI features with real model calls and to run a small evaluation; it changes the quality of product judgment.
How it's scored
Weak: Vague definition or dismisses it as hype.
Hire: Defines it and lists sensible PM uses.
Strong Hire: Adds a workflow with success criteria and testing, and clear boundaries on production code, data and understanding.
Common mistakes
Treating prototypes as shippable software.
Using real customer data in unapproved tools.
Testing with one happy example.