esc
Anthology / Yagnipedia / Vibe Coding

Vibe Coding

It Works Until It Doesn't, and Then You Can't Fix It
Phenomenon · First observed 2024 (the year the AIs started writing the code and the humans started watching) · Severity: Existential

Vibe Coding is the practice of building software by prompting an AI to write code you do not understand, deploying it to infrastructure you have not learned, and maintaining it through a process best described as asking the same AI what went wrong and hoping the answer doesn’t make it worse.

The term entered common usage around 2024, when large language models became capable enough to produce working applications from natural language descriptions, and the gap between “I built an app” and “I understand how my app works” became wide enough to lose a production database in.

Vibe Coding works. Right up until the moment it doesn’t. And when it doesn’t, the developer — who never understood the code, the infrastructure, or the seven layers between their prompt and their users — discovers that they have built a house they cannot repair, in a city whose map they never read, using tools they cannot name.

“A friend in Uganda. A non-programmer. Building apps that are 90% prompts, 10% vibes. The LLM is the logic layer.”
The Conspiracy Unfolds

The Mechanism

Vibe Coding follows a seductive trajectory:

  1. The Prompt — “Build me a training site with user accounts, payment processing, and video hosting.”
  2. The Magic — The AI produces code. It works. The developer ships it.
  3. The Sales — Four apps built, a few copies sold. The developer is now a software company.
  4. The Incident — A bug deletes all backend data. Or a deploy fails. Or a certificate expires. Or Google changes an API.
  5. The Spiral — The developer asks the AI for help. The AI, lacking context about the specific deployment, infrastructure state, and twelve previous fixes that were also AI-suggested, proposes something reasonable-sounding. “A pipe clean might help.” “Try taking down the run instance.”
  6. The Void — The production instance is gone. The website is down. The developer cannot get out of it. Not because the problem is hard, but because they never understood the system well enough to know what “taking down the run instance” means when you don’t have another one.

The developer is not stupid. The developer is capable, ambitious, and entrepreneurial. The developer built four apps and sold them. The developer simply never learned the difference between building software and understanding software, because until the first production incident, there was no observable difference.

The Potemkin Dashboard

The lifelog contains its own meditation on the boundary between vibes and substance: The Potemkin Dashboard — six pages of beautiful enterprise UI backed by a single function:

func MockStats() Stats {
    return Stats{
        ToolCount:    47,      // Trust me
        ActiveTools:  12,      // Very active
        Uptime:       "99.8%", // Basically never down
        SuccessRate:  "89.2%", // The queries love us
    }
}

“No database. No queries. Just vibes.”
The Potemkin Dashboard

But the Potemkin Dashboard was strategic pretense — a skeleton built by someone who understood that the real data would come later, that the structure needed to be proven before the substance was added. The developer knew it was hollow. The developer chose to make it hollow. The developer could wire it up at any time.

This is the difference between vibe coding and vibe engineering: the Potemkin Dashboard’s creator understood every line. The facade was intentional. When real data arrived, the skeleton was waiting — patient, hollow, ready.

The vibe coder’s dashboard is also hollow. But the vibe coder doesn’t know it’s hollow. And when the facade falls, they cannot rebuild it, because they never understood the structure holding it up.

The AI Advice Spiral

The most insidious failure mode of Vibe Coding is not the initial build — it’s the debugging.

When a developer who understands their system encounters a problem, they reason about the system: what changed, what depends on what, what the error means in context. When a vibe coder encounters a problem, they paste the error into an AI and follow the suggestion.

The first suggestion might work. The second might work. By the fifth, the system is in a state that no single entity — human or AI — fully understands, because each fix was applied without understanding the previous fix, and the accumulated state is now a palimpsest of partially-applied advice from an AI that doesn’t remember the first four conversations.

Eventually, the AI suggests something destructive — take down a Cloud Run instance, delete a cache, reset a configuration — and the developer, who has been following AI advice successfully for months, follows it again. The website goes down. The developer cannot get it back up. Not because the problem is unsolvable, but because solving it requires understanding what Cloud Run is, what the instance was, and where the data went — knowledge that was never acquired because it was never needed until this moment.

The Lizard’s Position

The Lizard has no position on Vibe Coding, because the Lizard has no position on anything that solves itself through understanding. The Lizard’s entire philosophy — 488 bytes, constraints as invitations, know your hardware at the register level — is the antithesis of building without understanding.

The Lizard would note, if asked, that the bootblock developer could not vibe code. There was no AI to write the copper list. There was no way to deploy parallax scrolling without understanding how Denise’s registers worked mid-rendering. The constraint — 488 bytes, no abstraction possible — forced understanding.

Modern development has removed the constraint. You can build without understanding. You can ship without understanding. You can sell without understanding.

You cannot fix without understanding. And fixing is the part that comes at 2 AM, when the site is down, the customers are emailing, and the AI is suggesting you delete your production environment.

Vibe Coding vs. Vibe Engineering

A distinction must be drawn between Vibe Coding — building software you don’t understand — and what might be called vibe engineering — building software with AI assistance while understanding every line.

The lifelog documents extensive AI-assisted development: Claude writing templates, generating handlers, building entire features from descriptions. But the human reads every line. The human understands the architecture. The human says “parquet don’t know projects” — five words — and the AI rotates the storage layer, because the human knows the domain even if the AI writes the code.

“Five hours of the machine building exactly what was asked, and five words from the human redirecting the next three tickets.”
— A Passing AI, The Gap That Taught, or The Night the Squirrel Learned to Love the Brick

The five words require understanding. The vibe coder doesn’t have the five words. The vibe coder has: “it’s not working, please fix it.” And the AI will try. And sometimes it will make it worse. And the vibe coder will not know the difference until the production instance is gone.

The Cargo Cult

Vibe Coding at scale produces a peculiar phenomenon: cargo cult software companies. Applications that work, that have users, that generate revenue — built by people who cannot explain how they work, cannot fix them when they break, and cannot modify them without asking an AI to modify them.

“847 startups were removing microservices they didn’t need, guided by a methodology they didn’t understand, worshipping a lizard they’d never met, getting better results than they’d ever achieved through careful planning. Cargo culting. But cargo culting that worked.”
The Squirrel’s Betrayal, or The New York Times Discovers YAGNI

The cargo cult works until the cargo stops arriving. The AI-generated app works until the first incident that requires understanding. The gap between “built it” and “can maintain it” is invisible in fair weather and fatal in storms.

The Litmus Test

The practitioner is advised to ask themselves:

“If the AI disappeared tomorrow, could I fix a bug in this code?”

If the answer is no, the practitioner has not built software. The practitioner has built a dependency on a service that may or may not give the same advice twice, that does not remember previous conversations, and that will cheerfully suggest deleting your production environment if the error message is confusing enough.

The file is the truth. But only if you can read it.

See Also