Chapter 15

Vibe Coding Practical Guide — When to Use It and When to Never

Chapter 15: Vibe Coding Practical Guide — When to Use It and When to Never

Learning goals: accurately define Vibe Coding's boundaries rather than blindly following or rejecting the trend; master 3 scenario types where Vibe Coding excels and 5 where it's dangerous; fully reproduce a 15-minute Chrome extension Vibe Coding session including real problems encountered; know the security checklist required before any Vibe output goes to production.

What Vibe Coding Is

Andrej Karpathy (former Tesla AI Director, OpenAI co-founder) coined the term in February 2025:

"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. I just see prompts, the AI responds, I run the code, it works or I complain and it fixes it. I don't read the code at all."

— Andrej Karpathy, February 2025

Core distinction from "AI-assisted coding": with AI assistance, you still read, review, and understand every line. With Vibe Coding, you skip that entirely. You describe the desired result, AI writes the code, you only look at whether it runs correctly. This delivers extreme speed — and risks you need to clearly understand before applying it.

3 Scenario Types Where Vibe Coding Excels

Scenario 1: Personal tools and scripts

Only you use it. No other users, no security requirements, it just needs to work. This is Vibe Coding's purest use case.

Examples: merging and deduplicating 200 CSV files; batch-renaming images by date/size/content; downloading YouTube subtitles and formatting them as docs; monitoring a webpage for changes and emailing you; batch-converting Notion Markdown exports to HTML.

Vibe Coding for 30 minutes beats spending 3 hours writing carefully. Code quality doesn't matter — it's throwaway.

Scenario 2: Prototypes and concept validation

The goal is validating whether an idea works, not shipping to production. If the direction is wrong, all the code gets thrown away. If it's right, you'll have time to rewrite it properly. Code quality is irrelevant; speed of validation is everything.

Examples: hackathon projects, product demos, A/B testing an interaction pattern, validating whether a third-party API integration is feasible.

Scenario 3: Non-critical UI and internal tooling

Admin dashboards, internal ops tools, one-off data migration scripts, employee-facing report pages. Low blast radius if something breaks, and operators are present to notice and report issues quickly.

5 Scenario Types Where You Should Never Vibe

Scenario Why Not Real Consequence
Payment and financial logic AI may use floats for money amounts (0.1 + 0.2 !== 0.3), may get refund/charge sequencing wrong Accounting errors, financial loss, user disputes
Auth and authorization AI may check "logged in" but forget "authorized to access this specific record" Unauthorized access, data breach
Encryption and decryption AI may use deprecated algorithms (MD5 for passwords, ECB mode) because old code dominates training data Passwords crackable by rainbow tables, encryption worthless
High-concurrency critical paths AI may write check-then-act instead of atomic operations — passes low-concurrency tests, fails under load Data inconsistency, production crash
Regulated features AI doesn't know your GDPR deletion requirements, financial reporting format, or healthcare data isolation rules Compliance violations, fines

The key question: Ask yourself — "If this code has a bug, what's the worst-case outcome?" If the answer is "feature temporarily unavailable, redeploy fixes it" — vibe freely. If the answer is "user data breach," "financial loss," or "compliance violation" — write it carefully and review every line.

Real Session: 15-Minute Vibe Coding a Chrome Extension

Goal: One-click send current page URL and title to a Telegram Bot.

Composer Prompt

Create a Chrome extension that, when the user clicks the toolbar icon,
sends the current tab's URL and title to a Telegram Bot.

Bot Token and Chat ID are configured in an Options page,
saved in chrome.storage.sync.

Files needed:
- manifest.json (Manifest V3, no background service worker needed)
- popup.html + popup.js (show "Sending..." then success/failure status)
- options.html + options.js (configure Bot Token and Chat ID, with save button)

Sending logic: call Telegram Bot API
  POST https://api.telegram.org/bot{TOKEN}/sendMessage
  body: { chat_id, text: "Title\nURL" }

Success: show green "Sent". Failure: show red error (e.g., "Invalid token").
No icon files needed — leave icons as empty array in manifest.

AI generated 4 files in ~90 seconds. Two real problems encountered during testing:

Problem 1: chrome.tabs permission missing. Extension loaded, clicked icon, immediate error: Error: 'tabs' permission required. Told AI: "Getting: tabs permission required." AI added "tabs" to permissions in manifest.json. Fixed immediately.

Problem 2: Manifest V3 blocks eval(). Initial popup.js contained an eval() call. Manifest V3's CSP blocks it. AI replaced eval() with JSON.parse(). Fixed.

// popup.js — AI-generated, two fixes applied
document.addEventListener('DOMContentLoaded', async () => {
  const status = document.getElementById('status')

  const [tab] = await chrome.tabs.query({ active: true, currentWindow: true })
  const { botToken, chatId } = await chrome.storage.sync.get(['botToken', 'chatId'])

  if (!botToken || !chatId) {
    status.textContent = 'Configure Bot Token and Chat ID in Options first'
    status.style.color = '#f87171'
    return
  }

  status.textContent = 'Sending...'
  status.style.color = '#a0aec0'

  try {
    const res = await fetch(
      `https://api.telegram.org/bot${botToken}/sendMessage`,
      {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ chat_id: chatId, text: `${tab.title}\n${tab.url}` })
      }
    )

    const data = await res.json()

    if (data.ok) {
      status.textContent = 'Sent'
      status.style.color = '#86efac'
    } else {
      status.textContent = `Failed: ${data.description}`
      status.style.color = '#f87171'
    }
  } catch (err) {
    status.textContent = `Network error: ${err.message}`
    status.style.color = '#f87171'
  }
})

Timeline: 0:00 start prompt → 1:30 AI generates 4 files → 2:00 load extension, permission error → 2:30 fix applied → 3:00 eval() CSP error → 3:30 fix applied → 4:00 fully working → 4:00–15:00 code review and security check.

What code review found: The implementation is fundamentally sound — no XSS risk (all output via textContent, not innerHTML), no hardcoded credentials, configuration stored in chrome.storage.sync. Minor issue: raw Telegram API error descriptions shown to user — acceptable for a personal tool, but production-grade code would sanitize these.

Quality Checklist: Vibe to Production

Security (all required):

Data and Performance (important):

Hybrid Strategy: Match Approach to Risk Level

Code Layer Recommended Approach Examples
Core business logic Handwritten + AI autocomplete assist Payment flow, authorization system, encryption
Feature modules AI generates framework, human reviews before accepting User settings, notification system, search
Utility functions Vibe + unit test verification Date formatting, data transformation, text processing
UI components Pure vibe, judge by visual output Loading spinner, Modal, form components
Scripts and tools Pure vibe, working = done Data migration scripts, build helpers

Chapter Key Points

  1. The core Vibe Coding decision criterion is risk level, not technical complexity. A complex data processing script can be vibed; a simple permission check cannot — because the former's failure scope is limited, while the latter's failure means user data at risk.
  2. 5 scenario types that must never be vibed: payment and financial logic, user auth and authorization, encryption/decryption, high-concurrency critical paths, regulated features. These don't produce "temporarily unavailable" bugs — they produce financial loss, data breaches, and compliance violations.
  3. Vibe Coding accelerates building; it doesn't replace learning. Generate code without understanding it and six months later you'll be just as lost in front of it. During the learning phase: think through your own approach first, then compare with AI's, understand the differences and why.
  4. Code review happens after behavior validation, not before. Vibe phase: validate that it works. Once it works: read the code. This is the correct order — reviewing first loses the speed advantage entirely.
  5. The pre-production security checklist is non-negotiable: no hardcoded secrets, parameterized SQL, input validation, no eval()/innerHTML injection, server-side auth checks. These 5 are the minimum bar — AI will not proactively remind you to verify all of them.
Rate this chapter
4.8  / 5  (16 ratings)

💬 Comments