Vibe Coding 的本质：不是魔法，是协议

The Essence of Vibe Coding: Not Magic, Protocol

In February 2025, Andrej Karpathy tweeted that he was "fully vibe coding" — "forgetting that code exists," just talking to Cursor in plain English. The tech community exploded. Half cheered "programming is dead." Half scoffed "another bubble."

Both are wrong.

Vibe coding is neither the end of programming nor a bubble. It's a new human-AI collaboration protocol — most people just haven't seen its structure yet. Let me lay it out.

Misconception #1: "You Don't Need to Learn Programming Anymore"

Every time someone asks me "so we don't need to learn to code anymore?" my answer is: no, you just don't need to learn syntax anymore. But you must learn something harder — how to precisely express requirements.

This sounds counterintuitive. Isn't natural language our native tongue? Doesn't everyone know how to talk?

The problem is that the gap between "talking" and "precisely expressing requirements" is vastly larger than the gap between "writing Python" and "writing C++." Ask a product manager to describe a "user login feature" and they'll produce a three-page PRD. Ask them to tell an AI exactly "what kind of login I want" and nine out of ten will say something like "just... a normal login, you know."

This is the context where the PARE framework was born. Four letters — Persona, Action, Restriction, Expectation — essentially 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?

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." This is writing input specifications for a compiler.

So "you don't need to learn programming" is only half true. You indeed don't need to hand-write for-loops anymore. But you must learn a higher-dimensional form of programming — programming intent. That's a far scarcer skill than syntax.

Misconception #2: "AI Code Doesn't Need Review"

Some people actually believe this. They have AI generate code, run it once, no errors, commit. These people are fundamentally identical to those who sign contracts without reading them — not optimistic, just lazy.

In traditional development, code review is human-to-human accountability. Write garbage and your colleagues will call you out. Social pressure keeps quality up. But in vibe coding, AI generates the code, and you have no social pressure toward a machine. So "review" gets quietly skipped.

That's precisely where the danger lies. Because AI-generated code has a unique property: it looks dramatically better than it actually is. AI-written code typically features clean formatting, elegant naming, thorough comments — creating an illusion of "this code is high quality." But look closer: logic gaps, missing edge cases, security vulnerabilities — the truly lethal problems — all hide beneath that polished surface.

This is why the audit loop exists.

The complete audit loop is five steps: Generate → Audit → Fix → Re-review → Write-back. Note: this is not traditional code review. Traditional review asks "is this code well-written?" The audit loop asks "is this code trustworthy?" Fundamentally different starting point.

The audit framework's design principle: default pessimistic, zero trust, code as ground truth. Meaning: every claim AI makes is treated as unsubstantiated until you find evidence for it in the code. The audit tool performs "multi-world 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. Every dimension is a potential disaster入口.

Some say this is too heavy. But think: in traditional development, your own experience was your implicit audit tool. You'd written similar code before, you knew where bugs tend to lurk, and that experience silently reviewed your work. In vibe coding, you've outsourced code generation to AI, so you've lost that implicit safety net. You must make the audit explicit, systematic, and tool-driven.

Review didn't become more important — review changed form. From "human intuitive审查" to "systematic engineering audit." Most people haven't made that mental shift yet.

Misconception #3: "Vibe Coding Has No Methodology"

"It's just chatting with AI. What methodology?"

People who say this probably have no methodology for managing their careers either. But I don't want to make this personal — I want to state a fact: in a single Prompt Vault, there are over 30 systematic methodology files covering five dimensions: prompt design, human-AI collaboration workflows, iterative audit, knowledge management, and cognitive tools.

Take the requirement closure process. It went through 6 versions of iteration, evolving from an initial concept model into an 11-step system-level framework. The core rhythm: one Spec confirmation to lock understanding → small-step per-task execution → exception gates that only interrupt when necessary → trimmable acceptance audit. The user makes decisions at exactly two points — Spec confirmation and exception gates. The rest of the time, keep vibing, let AI run.

What is this? This is "maximize human intent expression, minimize human cognitive load." Not casual conversation — a carefully designed interaction rhythm.

Or take the human-AI alignment protocol. It specifies that AI must not "over-execute" — given a vague requirement, AI shouldn't start coding immediately but should first propose 3-7 key clarifying questions, proactively identifying blind spots you might have missed. This "clarification-first" principle essentially inserts a "requirement precision gate" into the vibe coding process.

Then there's the MAKE framework — Minimal Actionable Knowledge — for identifying the "minimum necessary knowledge" in a domain. The LIKF layered knowledge framework — a 6-level progressive knowledge digestion system. The graph-traversal learner — controlling exploration depth with trunk-first strategy. Each tool solves a specific pain point in vibe coding.

Saying vibe coding has no methodology is like saying agile development has no methodology — it's not that there isn't one, it's that you haven't seen it.

The Truth: A Three-Layer Protocol Model

Alright, let's get to the point.

The essence of vibe coding is a three-layer protocol model:

Expression Layer (Vibe): Natural language. The human comfort zone. This is where you talk to AI. You say "build me a login page, make it look good, make it secure" — that's vibe. Vague, emotional, imprecise — but it's your most natural mode of expression, and it's where the name "vibe coding" comes from.

Protocol Layer (Structure): The PARE framework, the audit loop, the documentation system, the human-AI alignment protocol — the invisible engineering backbone you don't see but absolutely must exist. This layer's job: transform the Expression Layer's vague intent into executable, verifiable, auditable structured instructions. Without this layer, vibe coding is tossing coins into a wishing well.

Execution Layer (Code): Code implementation. AI's domain. AI receives structured instructions, generates code, undergoes audit, fixes issues, writes back documentation. Humans can avoid touching this layer entirely — but must monitor it through the Protocol Layer.

Most people's misconception about vibe coding is treating the Expression Layer as the whole picture. They see "talking to AI in plain English" and assume that's the entire magic. What they don't see is that the real magic-preventing-disaster is that invisible Protocol Layer in the middle.

An analogy: you see the driver gripping the steering wheel (Expression Layer). You don't see the steering system, suspension, braking system behind it (Protocol Layer), and the wheels ultimately turning on the road (Execution Layer). You can't claim "driving is just rotating a circular disc" just because that's all you do.

Why the Protocol Layer Is Necessary: The Real 80/20 Problem

Everyone who's tried vibe coding has encountered the 80/20 problem: first 80% of features, AI produces in seconds. Last 20% of polish, painful as pulling teeth.

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

The 80/20 problem isn't a capability problem — it's a context alignment problem. The first 80% is fast because Spec helped you and AI quickly align on core intent — you said "what I want," AI understood "what you want," match. The last 20% is slow because those details, edge cases, exception handling, and performance optimization require massive amounts of fine-grained context alignment. Every "no, that's not what I meant" exposes a context gap that was never closed.

The Protocol Layer solves exactly this problem.

The requirement closure loop's "one Spec confirmation + small-step execution" handles the first 80% — rapidly aligning core understanding through structured requirement input (one-line requirement + objects/scenarios + constraints + MVA + what we're not doing). The audit loop's "Generate → Audit → Fix → Re-review → Write-back" handles the last 20% — systematically discovering and filling context gaps through structured review.

See? This isn't making AI smarter. It's increasing the alignment efficiency between human and AI. The Protocol Layer's essence is a "context alignment accelerator."

The Philosophical Angle: Analytic Philosophy in Requirement Precision

This might be the most hardcore section, but it's the most worth saying.

Have you ever wondered why "expressing requirements" is so hard? From a philosophical perspective, it's because natural language is inherently ambiguous. You say "I want a secure login," and in your mind that's a clear idea. But the moment it's converted into natural language, it loses massive context — what counts as "secure"? SQL injection prevention? Brute-force protection? Two-factor authentication? Password policy requirements? Your "secure" and my "secure" might be completely different things.

Analytic philosophy offers a solution: proposition analysis.

Specifically, it decomposes vague natural language into three levels:

Atomic propositions: Irreducible basic facts. For example, "n1: Login requires username and password." "n2: Password transmission must be encrypted." "n3: 5 consecutive failures should lock the account." Each atomic proposition is a verifiable, testable, unambiguous statement.

Compound propositions: Combinations of atomic ones. "c1: (n1, n2, n3) → Login authenticates via username/password, transmission encrypted, failures trigger lockout." Compound propositions establish relationships between facts.

Modal propositions: Statements involving possibility and necessity. "m1: Under high concurrency, the login endpoint must support 1000 QPS." "m2: If the database is unavailable, the system should return a friendly degradation page."

Notice what happened? Proposition analysis turned a fuzzy "vibe" ("I want secure login") into a set of instructions that AI can precisely understand and execute. That's exactly the "Expression Layer → Protocol Layer" translation process in vibe coding.

What's more fascinating: the analytic philosopher's 8-step process — problem description → understanding → conceptual analysis → argument analysis → finding solutions → synthesis → verification → application — bears a striking structural resemblance to the requirement closure process. This isn't coincidence. Both processes are fundamentally doing the same thing: converting vague ideas into precise specifications.

So the core competency of vibe coding isn't "being good at talking." It's "being good at analyzing." Analytic philosophy's tools — conceptual clarification, proposition decomposition, logical argumentation — these are vibe coding's real "programming skills."

The Future: The End State of Prompt-as-Code

At this point, a deeper question surfaces: if prompts are becoming as structured as code, and code generation is becoming as natural as conversation, where's the boundary between "code" and "natural language"?

Answer: that boundary is dissolving.

Look at what Prompt-as-Code has already achieved in practice: prompts have version numbers (v1.0 → v3.0 evolution), dependency declarations (which context files this prompt depends on), exception handling (fallback strategy when AI encounters ambiguous input), and changelogs (every modification records the reason and impact scope). Prompts are integrated into document management systems with dedicated "Prompt First" templates, version-controlled alongside code.

Prompts are already first-class project citizens.

On the other end, code generation increasingly depends on natural language descriptions. Spec files (one-page requirement specifications) are becoming the starting point for code generation, not traditional technical design documents. You describe "what to build." AI decides "how to build it."

Two directions converging simultaneously — prompts becoming code-like, code becoming conversation-like. What's the end state?

I call it "Executable Intent": an expression form介于 natural language and programming language. To humans, it looks like describing intent. To AI, it looks like receiving instructions. It has human readability and machine executability. The Protocol Layer is the grammar specification for this "executable intent."

This isn't science fiction. PARE's 8-layer architecture is already a prototype of this direction — it's essentially defining a new "language," an intermediate representation that both humans and AI can understand.

A Response to Michal Malewicz

Michal Malewicz criticized vibe coding's output as "Ikea LACK coffee tables" — cheap, functional, soulless.

The critique has merit — if you only operate at the Expression Layer, vibe coding indeed produces Ikea-grade code. The functionality works, but there's no architectural thinking, no engineering aesthetics, no sense that "someone who truly understands built this."

But the critique misses something critical: soul doesn't come from vibe. Soul comes from Protocol Layer design.

Code that's been through a complete audit loop — 12-dimension security review, STRIDE threat modeling, change-impact analysis, continuous convergence via OODA loops — its quality is no worse than any human engineer's handiwork. A prompt designed through PARE's 8-layer architecture — clear role definition, precise task description, comprehensive exception handling — its structural rigor is no worse than any technical design document.

The problem with the Ikea coffee table isn't that it's machine-made. It's that nobody designed a soul for it. The Protocol Layer is where the soul gets注入.

Conclusion

Vibe coding isn't magic.

It's a protocol. A collaboration protocol between human and AI. Humans express intent (vibe). AI translates to execution (code). In between, a structured Protocol Layer guarantees quality.

This Protocol Layer is implicit — the user perceives natural language conversation, but behind it runs PARE's structured instructions, the audit loop's systematic quality assurance, the documentation system's context management, and propositional analysis's requirement precision. Not chaos — hidden order.

Karpathy said "forget that code exists." But that doesn't mean "forget that engineering exists." Exactly the opposite — when you're no longer distracted by syntax details, you should pour all your energy into Protocol Layer design: how to express intent more precisely? How to audit output more systematically? How to manage context more effectively?

The future belongs to those who can both vibe and structure. Those who only vibe produce Ikea coffee tables. Those who only structure are still hand-writing for-loops. Those who can do both — they're the ones truly mastering this new era.

Not magic. Protocol. Don't worship. Understand.