Vibe Coding vs Real Coding

Last tested and updated: June 2026

In a vibe-coding session, you describe what you want, let the AI write it, and click Run. It feels effortless until you try to ship. The project breaks in three places, the bug will not reproduce, and each “fix” introduces another hallucinated API. You have spent $40 without opening a test runner.

Andrej Karpathy named this practice vibe coding in early 2025. It is fast when the code is disposable and painfully slow when an untested prototype drifts toward production. This lesson helps you find that boundary.

This lesson covers when vibe coding is the right tool, when it is not, and how the two styles combine. See L01: Coding with Claude Code for the harness.

How each approach fails

The difference becomes clearer when you look at how each approach fails.

Vibe coding fails when you ask the AI for a drag-handler. It produces a drag-handler that looks right. The drop event never fires because nobody specified the drop target. You spend four rounds of “no, the other way.” The AI is reasoning about the wrong model of the problem.

Real coding fails when you spend 8 hours reviewing a 200-line diff for a UI button. The prototype was thrown out the next morning. You were right that the code would have bugs. You were wrong that the bugs mattered.

The trade is verification cost, not AI vs no AI. Verification is what costs you time. Vibe coding is verification-free by design. Real coding is verification-rich by design. The mistake isn’t picking one. The mistake is using one in the wrong quadrant.

The verification-cost matrix

The diagram you need is a 2x2. The x-axis is how seriously you intend to ship: from “throwaway” on the left to “long-lived production” on the right. The y-axis is how strict the quality bar is: from “looks right” at the bottom to “reviewed and tested” at the top.

The two diagonals on the diagram are the two spectrums most projects actually move along. The “ship the real thing” axis: throwaway script to production codebase with CI. The “kill it on Friday” axis runs the other way.

A few concrete examples to anchor the quadrants:

• Bottom-left, “throwaway + looks right”: a one-off script to rename 200 files, a personal cron, a quick HTML mockup. Vibe coding. Run it. Delete it.
• Bottom-right, “long-lived + light review”: an internal tool you’ll touch for a year. Hermes is excellent here: see Hermes L01: What Is Hermes Agent?. Agent harness, scheduled job, light review of what it produced.
• Top-left, “shipped + tested”: a SaaS MVP you intend to charge money for. Claude Code or Kilo Code, with a real test suite, and you read every diff before merging.
• Top-right, “production + reviewed”: a long-lived web app, a mobile app, a data pipeline, a public library. Real coding, full stop.

Decide what must keep working

Two questions decide which tool to reach for:

1. Will this code still be running in three months?
2. Will anyone (including future-you) be debugging it at 2am?

If both answers are “no”: vibe coding. If either answer is “yes”: real coding. If the first answer flips during the project, switch mid-stream. That’s normal and covered below.

When to vibe code

Vibe coding is right when the cost of a bug is low and the cost of being slow is high. Concrete cases:

• Exploration. Trying 5 UI variants before picking one. Trying 3 database schemas. The point is to throw most of them away.
• One-off scripts. Rename 200 files, scrape a page, generate a CSV. Run once, delete.
• Throwaway demos. “Show the team what a Slack-integrated todo app could look like.” Will never see production.

For all of these, the cheapest path is vibe coding with a Tier 2 model. Use DeepSeek V4, Kimi K2.7, or a local Qwen. The speed wins. The quality is “good enough for code you’ll throw out.” Keep the expensive models in reserve for production.

When to real code

Real coding is right when the cost of a bug is high: including the cost of a bug you’ll find in three months when you’ve forgotten what you wrote. Concrete cases:

• Anything user-facing that ships. Web apps, mobile apps, public APIs, public libraries. Use Claude Code or Kilo Code (covered in L01) with a real test suite, a Git workflow, and code review.
• Anything that touches money or data. Payment flows, auth, anything that writes to a database you can’t easily roll back.
• Anything that has to keep working. Cron jobs, scheduled tasks, automations that have to wake you up when they break.

For all of these, use a coding harness such as Claude Code or Kilo Code with a Sonnet-class model or above. The harness runs the loop, tests provide verification, and your review catches what the tests miss.

Combining both (the most common pattern)

Most production work in 2026 follows this pattern, in this order:

1. Vibe code the prototype. Try 5 UI variants. Pick the best one. The whole job here is to find out what you actually want.
2. Write a one-paragraph PRD. Inputs, outputs, edge cases. The PRD is the artifact that lets you switch from “AI proposes” to “I direct.”
3. Switch to a coding harness. Open Claude Code or Kilo Code on the prototype. Tell it the PRD, point it at the code, let it write the production version with tests.
4. Read every diff. You, not the harness. The harness proposes; you decide.
5. Run the tests. If they fail, the harness iterates. If they pass, you merge.

This is the “vibe for exploration, real for production” pattern. The vibe phase is fast and loose. The real phase is slow and verified. The boundary between them is the PRD.

Common failure modes

Four ways this goes wrong, in order of how often beginners hit them:

• Vibe coding production code. Ship the prototype. It works for 80% of users and breaks for the other 20%. The fix is the combine pattern above.
• Real coding a prototype. Do not spend a day testing code you already expect to throw out. Use vibe coding to explore, then switch to real coding after the PRD.
• Skipping the PRD. Without even a one-paragraph brief, the AI fills in the gaps with assumptions. The result may look right while missing your actual intent, leaving you to fix it across four rounds.
• Burning tokens on iteration. Ask the AI to fix a bug. The fix introduces a new bug. 20 iterations, $50 gone. A coding harness with a test suite catches the regression in round one.

Compare both approaches

Spend one hour on each, then compare.

The exercise

Pick a small project on your machine: a CLI tool, a single-page app, a script, anything that fits in an afternoon. Spend one hour vibe coding it. Don’t write a PRD. Don’t run the tests. Just describe what you want and ship it.

Then open Claude Code (or Kilo Code, from L01) on the same project. Spend one hour rebuilding it the “real coding” way: PRD first, harness writes code with tests, you read every diff, you run the test suite after each change.

At the end, write down in your own words:

• What was easier about the vibe-coding hour?
• What was easier about the real-coding hour?
• Which version would you actually ship?
• Where did the PRD change what the AI produced?

If your answer to question 3 is “the vibe-coded one” and you can articulate why, you’ve correctly identified a throwaway prototype. If your answer is “the real-coded one” and you can articulate why, you’ve correctly identified a thing that has to keep working. Either answer is fine. The point is to feel the difference.

What’s next

• L01: Coding with Claude Code: the coding harness.
• L03: Building Real Projects with Hermes: the vibe-then-real pattern on a real project.
• Hermes L01: What Is Hermes Agent?: agent harness for internal tools.

Check your understanding

Q1.You spend an hour vibe coding a personal cron that scrapes a weather page every morning. Is that the right tool?

1. No — vibe coding is always wrong.
2. Yes — it's a personal tool, low stakes, you'll throw it away if it breaks.
3. No — anything automated should be built with Claude Code.
4. It depends on which model you used.

Check answer

Q2.Short answer: what is the single artifact that lets you switch from vibe coding to real coding mid-project?

Reveal answer

Q3.You vibe coded a feature, it works on your machine, and the team wants to ship it next week. What is the right next step?

1. Ship the vibe-coded version as-is.
2. Open Claude Code or Kilo Code, write a one-paragraph PRD, rebuild the feature with tests, read every diff.
3. Just deploy the prototype and see if anyone complains.
4. Rewrite the whole project from scratch in a different language.

Check answer

Q4.Per the source quote, why does vibe coding break on drag-handlers?

1. Models don't understand drag-and-drop.
2. Vibe coding with intent-free prompts fills in gaps with assumptions, and those assumptions are often wrong on edge cases.
3. Drag-handlers require a coding harness.
4. Models can't generate event handlers at all.

Check answer

Q5.True or false: real coding means writing the code by hand without AI help.

Reveal answer

Q6.Which is the better production stack for an internal tool that only your team uses: a coding harness with tests, or Hermes with a vibe-coded skill?

1. Always the coding harness.
2. Always Hermes.
3. Either is fine, depending on the team — both can be production-grade for internal tools.
4. Neither — internal tools should be hand-coded.

Check answer