Vibe Coding in Practice

Here is what vibe coding actually looks like. Not a definition. Not a tutorial on which flags to pass. Real scenarios, real outcomes, the moments that make engineers stop mid-sentence and say "wait, that just worked?"

Every scenario below happened. The prompts are real. The time estimates are not padded. This is the workflow you are signing up for.

What you'll learn

• Vibe coding is describing what you want in plain English and watching it become a working system — not a prototype, not a demo, the real thing
• The skill is not "knowing what to type." It is knowing what to describe, what context to give, and when to step in
• Everything in Days 2-5 is about making this workflow reliable enough for production — the scenarios here are the "why;" the rest of the course is the "how"

Scenario 1: the feature that took four sentences

A product manager drops into Slack: "We need a way for customers to export their transaction history as a CSV. Date range picker, filters by category, download button. Should work with the existing transaction API."

Traditional development: read the transaction API code, design an export endpoint, write the query logic, handle date filtering, wire up CSV formatting, write tests, open a PR. Two to four hours of solid work.

Vibe coding:

> Read the transaction API at @api/transactions.py and add a CSV export endpoint.
  It needs: date range filtering (start_date, end_date query params), category
  filter, CSV output with columns: date, description, category, amount.
  Use the existing database query patterns. Add tests. Open a PR when done.

Claude Code reads the existing API code to understand the patterns. It writes the endpoint, the CSV formatter, the tests. It opens the PR. You review the diff — it followed the existing conventions because it read them first. The whole thing took about eight minutes, and you spent three of those reviewing the output.

The skill here is not the prompt. It is knowing to point at the existing code first so the output matches what is already there, not what the model would build from scratch.

Scenario 2: the bug that found itself

Production throws a 500. The error log says KeyError: 'customer_email' somewhere in the notification pipeline. It is 11 PM and you do not want to trace through seven files of notification logic.

> I'm getting KeyError: 'customer_email' in production. Here's the traceback:
  @traceback.txt. Find the root cause and fix it.

Claude Code reads the traceback, finds the file and line, reads the surrounding code, and identifies the issue: the notification function expects customer_email in the payload, but the upstream caller passes email instead. It was renamed in a refactor two weeks ago and nobody updated the notification path.

It writes the fix. The tests pass. You deploy. Eight minutes total, and you never opened a single file yourself.

This is not "the AI fixed my bug." This is "I described the symptom, gave it the evidence, and it did the investigation I would have done, in a fraction of the time." The skill: give it the actual error, not your description of the error.

Scenario 3: the report that should have taken all morning

Your boss needs a competitive analysis of three companies before an 11 AM meeting. It is 9:30. You need pricing, recent news, product positioning, and a summary slide.

> Research Company A, Company B, and Company C. For each: current pricing tiers,
  recent news (last 3 months), product positioning, key differentiators. Write a
  briefing document with an executive summary, a comparison table, and a
  recommendation. Save to docs/competitive-briefing.md.

Claude Code searches the web for each company, pulls pricing from their sites, finds recent news articles, synthesizes the information, and writes a structured briefing document with a comparison table and a recommendation. You spend the remaining hour verifying the facts and formatting the output. The document is in your boss's inbox at 10:45.

The skill here: describe the output format as specifically as the research task. "Write a briefing document" produces something generic. "Executive summary, comparison table, recommendation" produces something useful.

Scenario 4: the refactor you were dreading

The codebase has 47 API endpoints. All of them catch exceptions individually with slightly different patterns. Some log the error and re-raise. Some swallow it. Some return a 500 with no logging at all. You need consistent error handling across all 47, and you have been putting it off for two months.

> Read every endpoint in @api/endpoints/. Currently each endpoint handles errors
  differently. Standardize all of them to use the error handler pattern from
  @api/error_handler.py. Do not change any business logic. Keep all existing
  behavior for successful paths. Run the test suite after each endpoint change.

Claude Code reads each endpoint file, applies the standard error handler pattern, runs the tests, fixes anything that breaks, and moves to the next. It takes about 20 minutes for all 47 endpoints. The test suite passes. The error handling is now consistent, and you never wrote a single try/except block.

This is the power of the workflow: describe the pattern once, point at the target, and let the agent do the mechanical work across every instance. The skill: be specific about what NOT to change. "Do not change any business logic" is as important as "standardize error handling."

Scenario 5: the side project that became a product

You had an idea for a tool that monitors competitor pricing and alerts you when something changes. On a Saturday afternoon. By Sunday evening it was running in production, checking three competitors every hour, sending Slack alerts when prices changed, with a simple dashboard showing price history.

You did not write a business plan. You did not set up a project board. You described the idea in a paragraph, Claude Code scaffolded the project, you iterated on the output in five rounds of "make it do X instead of Y," and it was live before dinner. The code was clean. It had tests. It deployed to a $6/month VPS.

This is the scenario that gives vibe coding its name: the distance between "I have an idea" and "it exists" collapses. The skill is iteration — describe, review, redirect, repeat — not crafting the perfect prompt on the first try.

What these scenarios have in common

Every one of them follows the same pattern:

1. Describe the outcome, not the implementation. "Add a CSV export endpoint" not "write a function that calls the transaction model and formats the result."
2. Give it context it can read, not context you summarize. @api/transactions.py not "the transaction API which does X and Y and Z."
3. Be specific about constraints. "Do not change any business logic" prevents the most common failure mode: the agent enthusiastically refactoring everything.
4. Iterate. The first output is rarely perfect. The second or third usually is. This is a conversation, not a command.

The rest of this course teaches you how to make this workflow reliable. How to give agents memory so they remember what they did yesterday. How to defend against bad input. How to ship to production. How to know when something breaks before a user tells you.

But the core skill — describing what you want and watching it happen — starts here. The next lesson shows you the tools that make it possible.

Next: What Makes an Agent — the one mechanical difference between a chatbot and the thing that just built your competitor report.