What Is Vibe Coding? Its Limits and the AI Code Check Loop

Vibe coding is when you throw out your intent in words and an LLM fills in the code. In Part 1 we saw the limits of a single prompt: no state, no tools, and no verification. In the world of code, the first thing to shake those limits was vibe coding. In February 2025, a phrase from Andrej Karpathy became its name ^[1]: "forget that the code even exists" and "fully give in to the vibes."

> Part 2 of the "Evolution of LLM use" series. ① Prompting · ② Vibe coding · ③ Agents · ④ Harness engineering · ⑤ Open models.

What vibe coding opened up: the friction of building disappeared

The core of vibe coding is raising the level of abstraction by one notch. Where we used to write every line ourselves, now we state the intent, "I want to build something like this," and the LLM fills in the code. We look at the result and fix it again in words.

This solved two things. First, speed: the time to build a prototype dropped from hours to minutes. Second, accessibility: you no longer have to memorize all the syntax; if your intent is clear, you can build something. The friction of building dropped sharply.

But a "feeling" isn't verification

The problem is that vibe coding inherited one limit straight from prompting: the absence of verification. Code that looks like it runs isn't necessarily right.

• It looks like it works: If you check only the happy path and move on, it quietly breaks on edge cases.
• Code you don't understand piles up: It isn't code you wrote, so you can't debug it either, and technical debt accumulates fast.
• Security and correctness get skipped: "It runs?" and "It's right" are different. A feeling can't guarantee the latter.

The well-known vibe coding joke is "works until it doesn't." It works until it doesn't, and at that moment nobody knows why.

Here's how relying on feel compares with adding a verification loop.

Don't stop the vibes; add verification

The fix isn't to quit vibe coding. Keep building fast, but add a verification loop after generation: intent → generate → actually run → verify → merge if it passes. This is also the rule we use when we work with code. Build in an isolated workspace, actually run it to check, and only then merge.

# (1) Vibe: output goes straight to main; it only "looks like" it works
# (2) Harness: isolate -> generate -> verify by actually running -> merge only if it passes
git worktree add ../wt-feature -b feature/x   # isolated workspace
#   (the LLM implements inside wt-feature)
cd ../wt-feature
pytest -q && pnpm typecheck                    # verify by running, not by guessing
#   merge if it passes, otherwise try again; main never breaks

The core is one line: "Don't stop at a guess; look at the actual result." It lays verification down as the floor beneath the speed vibe coding created. Isolation makes failure safe, and execution turns "looks like it works" into "works."

In short

Vibe coding erased the friction of building and opened up speed and accessibility. But it still carries prompting's "no verification," so without a verification harness you're stuck in "works until it doesn't." Build fast, but isolate, run, and verify: that's the small edge that lifts vibes into real work.

So far, a person ran the loop. We built, ran, and fixed. What if the model ran the loop on its own, using tools and watching the results? That's the next part: agents.

For related reading, see How to write good prompts: pin down AI output with context design, What is an AI agent? Permissions and approval gates when the model runs its own loop, and What is first-party data? How to use it in marketing after third-party cookies.