Module 11

Vibe Coding for Product Managers

Use AI coding tools to turn ideas into testable prototypes — safely — and know exactly where a prototype ends and production engineering begins.

≈ 10 h studyDraftedSources: Lectures 42, 43, 48, 49, 50; Companion ch. 20, 21, 22, 23, 24, 26, 28

Mark module complete Expand all

On this page

1. What vibe coding means
2. PM use cases
3. AI coding tools — categories
4. Prompt-to-prototype workflow
5. Git and GitHub fundamentals
6. HTML, CSS and JavaScript fundamentals
7. Building basic web applications, API integrations and databases
8. Deployment fundamentals
9. Debugging and testing AI-generated code
10. Security risks of generated code
11. Prototyping versus production development — and when engineering review is necessary
12. Building and validating MVPs with vibe coding
13. Hands-on project: from idea to deployed prototype
14. Exercises with model answers
15. Interview perspective
16. Key takeaways
17. Check your understanding
18. Recommended resources

11.1 What vibe coding means

Vibe coding is building software by describing what you want in everyday language and letting an AI coding tool write and change the code, iterating by testing the result and giving feedback. The term was popularised by Andrej Karpathy in early 2025.

11.2 PM use cases

11.3 AI coding tools — categories

11.4 Prompt-to-prototype workflow

A good build prompt (template)

Context: I'm a PM testing a hypothesis: [one sentence]. Users: [who].
Build: a single-page web app using plain HTML, CSS and JavaScript (no frameworks, no build step).
Core flows: 1) … 2) … 3) …
Data: fictional sample data only; store state in localStorage.
Must handle: empty state, loading state, an error state where [service] fails (show a clear message, never invent data).
Accessibility: labels for inputs, keyboard operable, visible focus, buttons ≥ 44px tall, colour contrast ≥ 4.5:1.
Constraints: no external API keys, no real payments, no personal data. Mark the page "Prototype".
Output: index.html, style.css, app.js. Then explain how to run it and list what is simulated.

11.5 Git and GitHub fundamentals

git init

git add index.html style.css app.js README.md

git commit -m "Fee-Clear Cart: first working prototype"

git checkout -b fee-fallback

git push -u origin fee-fallback

11.6 HTML, CSS and JavaScript fundamentals

• HTML gives structure and meaning: headings, lists, buttons, forms. Semantic HTML (<button>, <label>, <main>) is also what makes pages accessible.
• CSS controls presentation: layout (flexbox, grid), colour, spacing, responsive rules (@media).
• JavaScript adds behaviour: respond to clicks, update the page, call APIs, store data.

<label>Delivery area
  <select id="area"><option value="near">Within 3 km</option></select>
</label>
<button id="pay" type="button" disabled>Pay</button>

.pay { width: 100%; min-height: 44px; background: #2563EB; color: #fff; }
@media (max-width: 480px) { .wrap { padding: 12px; } }

document.getElementById("pay").addEventListener("click", () => {
  document.getElementById("result").textContent = "Simulated order placed (no payment taken).";
});

11.7 Building basic web applications, API integrations and databases

Calling an API from JavaScript (illustrative; a real API needs its own URL, authentication and terms):

async function getForecast(city) {
  const res = await fetch(`https://api.example.com/forecast?city=${encodeURIComponent(city)}`);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);   // handle 4xx/5xx explicitly
  return res.json();
}

Key rules: never put secret API keys in frontend code (anyone can read them) — call such APIs from a server or serverless function; handle failures, timeouts and rate limits; respect API terms.

Data storage ladder for prototypes:

11.8 Deployment fundamentals

• Static hosting (no server code): GitHub Pages, Netlify, Vercel, Cloudflare Pages — upload HTML/CSS/JS, get a URL.
• App hosting (server code + database): Replit deployments, Render, Railway, Vercel/Netlify functions, cloud providers.
• Environments: keep a test URL separate from anything real users rely on.
• Before sharing a link: remove secrets, check visibility, add a “prototype” banner, confirm data handling, and know how to take it down.

11.9 Debugging and testing AI-generated code

Debugging loop: reproduce → read the actual error (browser Console, Network tab, server logs) → tell the AI the exact symptom and error text → ask it to explain the cause before changing code → apply the smallest fix → re-test → commit.

Testing generated code (as a PM you can always do the first three):

1. Manual test plan: happy path, empty state, error states, invalid input, reload/persistence, mobile width, keyboard-only, slow network.
2. Acceptance criteria from your PRD, checked one by one.
3. Ask the AI to write tests — then read them: do they test behaviour you care about, or just that the code runs?
4. Automated tests (unit/integration/end-to-end) for anything that will live longer than a demo.
5. Peer review of the diff before merging.

11.10 Security risks of generated code

11.11 Prototyping versus production development — and when engineering review is necessary

Engineering review is necessary before: any real user data or personal information; authentication or payments; integration with company systems; anything customers rely on; anything public under the company's name; anything that runs automated actions (emails, money movement); any code that will be reused in production.

11.12 Building and validating MVPs with vibe coding

Use the speed to test assumptions, not to skip discovery: (1) pick the riskiest assumption; (2) build the smallest prototype that tests it; (3) put it in front of 5–8 target users with a task; (4) measure behaviour (task success, time, errors) and listen; (5) decide: iterate, pivot, or stop. A polished demo is not evidence of demand.

11.13 Hands-on project: from idea to deployed prototype

Project: Fee-Clear Cart — test whether showing the full estimated total in the cart reduces checkout surprise. The finished starter code is in templates/vibe-coding-starter/ (open index.html; it runs offline). It was tested in a browser at 375 px width: adding items, changing the area, simulated fee failure (“Estimate unavailable”, Pay disabled, Retry), and the simulated order message all behave as specified, with no console errors.

Step 1 — Brief (example). Hypothesis: first-time buyers who see the full estimated total in the cart will complete checkout more confidently. Users: busy office workers ordering dinner on mobile. Flows: add items; see estimated total; handle fee-service failure. Metric for the user test: % of participants who correctly state the total before tapping Pay (target ≥ 5 of 6).

Step 2 — Prompt. Use the template above. Ask for plain HTML/CSS/JS and a simulated fee service with a failure mode.

Step 3 — Review. Read app.js: find where the fee is fetched; confirm that on failure it shows “Estimate unavailable” and disables Pay (it does — feeState.status = "error"). Check labels, focus styles and button height in style.css.

Step 4 — Test. Run the checklist in the starter's README (add/remove, area change, failure + retry, keyboard-only, reload persistence, 375 px width).

Step 5 — Version. Commit after each working step; push to a branch; open a PR describing what changed and how you tested it.

Step 6 — Deploy. Public GitHub repo (dummy data only) → Settings → Pages → Deploy from branch main / root → share the URL with the Prototype banner visible. Do not add analytics that collect personal data; if you need behaviour data, observe sessions or log anonymous counts with consent.

Step 7 — Validate. Five or six moderated sessions: “You want this biryani and raita delivered 5 km away. How much will you pay in total? Now place the order.” Record task success, hesitations and quotes.

Step 8 — Decide. Readout: what you tested, results (e.g., “5 of 6 stated the correct total before paying; 1 missed the ‘est.’ label”), what you'll change, what remains unproven (real fee accuracy, real conversion), and the next test (A/B in the real product — Module 7).

11.13.1 Portfolio presentation

Include: the problem and hypothesis; a 60-second screen recording; the live prototype link; what is simulated; test method and real results (or “not measured”); what you learned; how a production version would differ (security, data, scale); and your role (be specific about what the AI generated vs what you decided and tested).

11.14 Exercises with model answers

Model answer

(1) Move the API call server-side (serverless function) and rotate the exposed key. (2) Render comments with textContent or sanitise to prevent XSS. (3) localStorage means each customer sees only their own browser's data — if shared data is intended, add a backend with access rules. (4) Add a prototype banner, privacy notice, and get engineering/security review because real customers are involved.

Model answer

“When I add 'Paneer wrap' the total never appears. Console error: TypeError: Cannot read properties of undefined (reading 'price') at subtotal() in app.js. Before changing code, explain the likely cause. I suspect the cart contains an id not present in MENU. Propose the smallest fix and a test I can run to confirm. Don't change any other behaviour.”

Model answer

Engineering (data access method, read-only replica, performance), security/IT (credentials, access control, approved tools), data/privacy (PII exposure, retention), and the data owner (permission). Even read-only access to production data is a production concern; use an approved read-only replica or an extract with minimised fields.

11.15 Interview perspective

“How do you use AI coding tools as a PM?” — 60-second answer

“I use them to make ideas testable quickly — clickable prototypes with fictional data that I put in front of users within days. I write a short brief with the hypothesis, flows, states and accessibility needs, build in small steps, test each one, and keep everything in Git. I label what's simulated, never use real customer data, and I hand off to engineering for anything with real data, auth, payments or customers relying on it. The value is faster learning, not shipping AI-written code to production unreviewed.”

“Walk me through a prototype you built.” — structure

Problem and hypothesis → users → what you built (stack, scope, what's simulated) → how you tested it (sessions, metrics) → results (real numbers or “not measured”) → what you'd do next → what engineering would need to productionise it. Be explicit about your contribution versus the AI's.

11.16 Key takeaways

• Vibe coding accelerates learning; it doesn't remove the need for engineering judgment.
• Work in small, tested, committed steps; describe symptoms precisely when debugging.
• Know HTML/CSS/JS, Git, APIs and storage well enough to review what the AI produced.
• Never put secrets in frontends, never use real customer data in unreviewed prototypes, and label simulations.
• Bring in engineering review before real data, auth, payments, integrations or public company use.

11.17 Check your understanding

11.18 Recommended resources

• MDN: Learn web development — HTML, CSS, JavaScript basics.
• GitHub Docs: Hello World and GitHub Pages quickstart.
• Claude Code documentation · Cursor docs · GitHub Copilot docs.
• Lovable docs and Replit Agent docs (from your course notes).
• OWASP Top 10 — common web security risks.