Vibe Coding：从 Karpathy 的直觉到工程化的实践

Vibe Coding: From Karpathy's Intuition to Engineered Practice

In February 2025, Andrej Karpathy tweeted that he was "fully vibe coding" — talking to Cursor's chat window in plain English, "forgetting that code even exists," and letting AI handle everything. Within hours, the tweet tore through the entire tech community.

What made it explosive wasn't the content. It was the author. Karpathy co-founded OpenAI. He ran Tesla's AI division. He carries unquestioned technical authority in deep learning. When someone with that pedigree says "I don't write code anymore," people pay attention.

But the real story isn't the tweet itself. It's what happened next: in the months that followed, "vibe coding" evolved from a viral meme into a serious methodological discussion. Medium filled up with analytical deep-dives. GitHub saw dedicated prompt repositories. The community, through sheer trial and error, started assembling reusable engineering frameworks.

This article traces that arc — from intuition to methodology.

I. Three Camps: What the Community Is Actually Arguing About

The community split fast.

The Optimists saw a paradigm shift. Their evidence was direct: Karpathy himself shipped entire projects this way, and the results ran fine. If a top-tier engineer could "forget code," everyone else should lean in harder. The optimist posture: "Skip the syntax. Learn to talk."

The Skeptics took the opposite end. Michal Malewicz, a prominent design voice, compared vibe-coded output to "Ikea LACK coffee tables" — cheap, functional, and utterly soulless. The skeptic's core concern: AI-generated code looks dramatically better than it is. Clean formatting, elegant naming, thorough comments — these are surface-level pattern matching. The real killers — logic gaps, missing edge cases, security holes — hide beneath that polished exterior. Worse, because you didn't write the code, you have no intuitive understanding of it. When things break, you don't even know where to start looking.

The Pragmatists staked out the messy middle. They acknowledged vibe coding's efficiency but rejected the "just talk and forget" narrative. Their key insight: vibe coding isn't a binary switch — it's a spectrum. You choose how much AI介入 at different granularities. The question isn't whether to vibe code, but how to make it not crash in production.

Here's what's interesting: if you actually read through a dozen-plus Medium articles on vibe coding, a consensus starts to emerge. The three camps don't fundamentally disagree about vibe coding itself. They disagree about whether vibe coding *needs* methodology. Optimists say no (it's just conversation). Skeptics say it's impossible (AI is unreliable). Pragmatists say not only yes — but we need an entirely new engineering methodology.

This article stands with the pragmatists.

II. The Core Challenges: Why "Just Talk" Doesn't Work

Before laying out methodology, we need to name the three core technical challenges. Understanding these gives the methodology its leverage points.

2.1 The 80/20 Problem

Everyone who's tried vibe coding has hit this wall: the first 80% of features, AI produces in seconds. You think "programming really is revolutionized." Then the last 20% — edge cases, exception handling, performance tuning, security hardening — becomes agonizingly slow. Every round of revision feels like playing charades with a machine.

Most people blame "AI isn't strong enough yet." Wrong diagnosis.

The 80/20 problem is fundamentally a context alignment problem. The first 80% is fast because core intent is easy to align — you say "I need a login page," AI understands "login page," boom. The last 20% is slow because it demands fine-grained, granular context alignment. Every "no, that's not what I wanted" exposes a context gap that was never closed. You're not writing code — you're iteratively correcting the misalignment between you and the AI.

2.2 Context Management

This runs deeper. AI context windows are finite. Real project context is effectively infinite. How do you make AI understand your project structure, tech stack choices, existing design decisions, team coding conventions? In traditional development, you acquire these through osmosis — you've been in the project for three months, you naturally know why you chose MongoDB over PostgreSQL. In vibe coding, every conversation is a fresh context injection. You must manage this information explicitly.

This isn't just a technical problem — it's a cognitive load problem. Developers spend half their energy on "making AI understand my project" rather than "solving the actual problem."

2.3 Code Quality Credibility

AI-generated code has a unique trap: it looks significantly better than it actually is. Proper formatting, sensible naming, adequate comments — these are language model strengths because they're pattern-matching tasks. But logical correctness, edge case handling, security防护 — these require deep reasoning, which is precisely where current AI falls short.

The deeper issue: in traditional development, your own coding experience serves as an implicit quality gate. You've written similar code before, you know where bugs tend to hide. This experience silently audits your work. In vibe coding, you've outsourced code generation to AI, so you lose that implicit safety net. And you haven't built an explicit audit mechanism to replace it. Code quality becomes a black hole.

III. The Community's Engineering Response: Five Pillars

Faced with these three challenges, the community didn't sit around waiting for AI to get stronger. Through practice, they assembled an engineering response. I organize these into five pillars.

3.1 The PARE Framework: Structured but Implicit

PARE is a widely adopted structural framework in prompt engineering that decomposes any effective prompt into four building blocks: Persona (role), Action (task), Restriction (constraints), Expectation (output criteria).

Sounds simple. But its deeper significance is routinely underestimated. PARE isn't a "prompt template" — it's a requirement compression protocol. It forces you to clarify four critical dimensions before you open your mouth: what role should AI play? What action should it perform? Within what boundaries? What standards must the output meet?

Example. Without PARE: "Build me a file upload feature." With PARE, the same requirement becomes:

• Persona: You are a backend engineer with 10 years of experience
• Action: Implement a file upload API supporting multiple files and resumable uploads
• Restriction: Max file size 100MB, types limited to images and PDFs, no external storage services
• Expectation: Output complete API code with corresponding error handling logic

Same intent, vastly different output quality from AI.

By v3.0, PARE evolved into an 8-layer architecture: Meta-information, Context, Persona, Task, I/O, Examples, Evaluation, Exception Handling. Look at that structure — this isn't "writing prompts" anymore. This is writing input specifications for a compiler.

That's the core meaning of "structured but implicit": the user perceives natural language conversation (vibe), but behind it runs a strict structural protocol. Prompt engineering at its essence: hiding engineering-grade structure beneath natural language.

3.2 The Audit Loop: From "Generate Once" to "Continuous Convergence"

If PARE solves "how to make AI generate the right code," the audit loop solves "how to ensure the generated code is actually right."

The complete audit loop is five steps: Generate → Audit → Fix → Re-review → Write-back.

Note: this is fundamentally different from traditional code review. Traditional review asks "is this code well-written?" The audit loop asks "is this code trustworthy?" Completely different starting point.

In practice, the audit framework operates on a design principle of "default pessimistic, zero trust, code as ground truth." The audit performs systematic analysis across 12 dimensions: control flow, execution model, state management, time handling, error handling, input validation, data consistency, dependency management, configuration management, structural integrity, performance, observability. Each dimension is a potential risk vector.

Some will say "this is too heavy." But think about it: in traditional development, your own experience was your implicit audit tool — you silently performed these checks. Vibe coding outsources code generation, so you must make the audit explicit. The weight hasn't increased — it's just shifted from implicit to visible.

This loop directly addresses the 80/20 problem: the first 80% completes fast through Spec lock-in and small-step execution, the last 20% converges through the audit loop. You're not playing charades with AI — you're using systematic review to discover and fill context gaps.

3.3 Prompt-as-Code: Prompts as First-Class Citizens

This might be the most forward-looking pillar.

Prompt-as-Code's core argument: prompts should be managed like code. Specifically, prompts should have version numbers (v1.0 → v3.0 evolution history), dependency declarations (which context files does this prompt depend on), exception handling (fallback strategy when AI encounters ambiguous input), and changelogs (every modification records the reason and impact scope).

This is more than a management practice — it's a cognitive framework shift. When prompts have version history, you can review "how I learned to communicate with AI" the same way you review code evolution. When prompts have dependency declarations, you manage context dependencies the way you manage code dependencies. When prompts have exception handling, you design prompt robustness the way you design system robustness.

In practice, this means a dedicated prompts/ directory in your project repository, sitting alongside src/ and docs/. Prompts are project first-class citizens — version-controlled, reviewed, tested, just like code.

3.4 Mature Paradigm Priority: Don't Let AI Reinvent Wheels

A deceptively simple but critically important principle: when directing AI to execute tasks, prioritize proven, battle-tested technology paradigms over letting AI invent from scratch.

Why? Because AI has a tendency: given free rein, it generates "plausible-looking" solutions that aren't necessarily "battle-tested" solutions. AI's knowledge comes from the statistical distribution of training data, not from the blood-and-tears lessons of engineering practice. It knows "how you could do it" but not necessarily "how you should do it."

Concretely, this means your prompts should include explicit technical constraints: "Use Express.js, not a custom HTTP server." "Use JWT, not a custom auth scheme." "Use an existing ORM, not concatenated SQL." You're using your engineering experience to constrain AI's generation space — letting it perform on proven paths rather than冒险 on untested ones.

3.5 Document-Driven Development (SSOT): Single Source of Truth

The engineering response to context management ultimately lands on document management.

The core concept is SSOT — Single Source of Truth. In vibe coding, code changes fast, documentation容易 falls behind, and outdated docs mean stale AI context, which means declining generation quality. A vicious cycle.

The solution is Document-Driven Development: treating the project's docs/ directory as the唯一 authoritative information source, keeping docs synchronized with code. Specific practices include:

• Every document has six mandatory fields: Purpose, Scope, Status, Evidence, Related docs, Changelog
• Clear decision logic: if a fact can't be derived from project evidence, mark it "to be confirmed." If docs conflict with code, code wins
• Git hooks checking whether code changes include doc updates
• Architecture decisions recorded using ADR (Architecture Decision Record) templates

This isn't traditional "writing docs" — it's building a sustainably consumable context library for AI. Every conversation with AI is traceable. Every decision has an ADR record. AI in subsequent conversations can回溯 this information. You're using documentation to "inject project memory" into AI.

IV. The Methodology Panorama: Seven Core Design Patterns

Distilling the practices above, we can identify seven core design patterns for vibe coding. These aren't theoretical deductions — they're patterns that repeatedly emerged from community practice.

Pattern 1: Structured but Implicit

The user perceives "natural language conversation" (vibe), but behind it runs a strict PARE/8-layer architecture. This is the foundation of the entire methodology — the "vibe" in vibe coding isn't casual. It's a carefully designed natural language interface with an engineering-grade structural skeleton.

Pattern 2: One Alignment + Small-Step Execution

Whether it's the requirement closure loop (one Spec confirmation + per-task execution) or human-AI alignment (one clarification + incremental deepening), both follow the same rhythm: align understanding upfront in one shot, then move fast in small steps. Users only need to make decisions at key nodes (Spec confirmation, exception gates). The rest of the time, stay in flow state and let AI execute.

Pattern 3: Audit-Driven Convergence

Generate → Audit → Fix → Re-review → Write-back. AI's first output is never perfect, but through systematic audit cycles, you converge toward production-grade quality. This isn't "write one good prompt and get good code." It's iterative: "every round is better than the last."

Pattern 4: Truth-First

"Code as ground truth." "Zero trust, verify everything." "No mock/stub/demo allowed." All methodologies point to one principle: only trust verifiable facts. Every AI assertion is suspect until you find evidence for it in the code. This isn't pessimism — it's engineering discipline.

Pattern 5: Depth Control + Trunk Priority

Graph-traversal learning limiting exploration depth, the MAKE framework's 80/20 rule, requirement closure's P0/P1/P2 priorities — these practices share a core: "grab the trunk first, control divergence." With limited context windows, you must ensure trunk-path correctness before filling in details.

Pattern 6: Prompt-as-Code

Prompts have version numbers, dependencies, exception handling, changelogs — integrated into the project's document management system. Prompts are no longer "byproducts of one-off conversations." They're persistent project assets.

Pattern 7: Mature Paradigm Priority

"Find a mature solution first, adapt it second, build from scratch only as a last resort." Before letting AI自由发挥, use your engineering experience to frame technology choices, keeping AI on proven paths rather than冒险 on unverified ones.

V. Conclusion: Not "No Structure" — "Hidden Structure"

Let's return to Karpathy's tweet. He said "forget that code exists." But if you interpret that as "forget that engineering exists," you're catastrophically wrong.

The essence of vibe coding isn't "no structure." It's "structure hidden beneath natural language."

What the user sees — talking to AI in plain English, describing requirements, reviewing results — is the Expression Layer. But behind it runs a complete Protocol Layer: the PARE framework converts vague intent into structured instructions, the audit loop transforms untrusted code into verifiable output, the documentation system turns scattered context into sustainably manageable information assets, and propositional analysis tools convert ambiguous natural language into testable precise statements.

It's like "invisible design" in UX — the user perceives smooth, natural interaction, but behind it lies carefully designed information architecture, interaction flows, and exception handling. You don't say an app's code is simple just because the app is easy to use. Likewise, you shouldn't say vibe coding needs no methodology just because it feels like chatting.

The truly effective vibe coder isn't the one who's best at "chatting." It's the one who's best at "designing structure." They know when to use the PARE framework for a precise requirement alignment, when to trigger the audit loop for systematic quality checking, when to pause and write an ADR for an important architecture decision. Their "vibe" isn't casual — it's supported by carefully designed structure.

So if I had to summarize the methodological core of vibe coding in one sentence:

Maximize the freedom of human intent expression while minimizing cognitive load, ensuring output quality through implicit engineering protocols.

This isn't magic. It's protocol. Not "forgetting structure" — "building structure so well you don't feel it."

Like good infrastructure — you don't notice electricity until it goes out. Good vibe coding methodology is the same — you don't notice the structure until you try working without it, and everything collapses.

Karpathy's tweet was the starting point. But the road from intuition to methodology — that's on us to walk.

*Methodology sources in this article were synthesized from analysis of approximately 30 core files in the Prompt Vault project, spanning prompt design, human-AI collaboration workflows, audit systems, knowledge management, and cognitive tools.*

*Written: April 2026*