Vibe Programming: A Protocol-First Paradigm
Vibe Programming describes a shift in how system behavior is specified and executed.
Instead of treating code as the primary instruction language, Vibe Programming uses human-readable protocols as the authoritative source of behavior.
Large language models act as interpreters of these protocols, executing multi-step workflows defined in structured text such as Markdown. Code becomes optional, incidental, or auto-generated — no longer the central artifact.
This approach builds on ideas popularized by “vibe coding,” but moves beyond rapid code generation toward protocol-governed execution.
What “programming” means here
At its core, programming has always meant specifying behavior through instructions.
Code is only one possible execution medium.
Vibe Programming makes this explicit.
-
Instruction language
Human-readable text: Markdown, structured prose, or protocols -
Interpreter
An LLM that interprets explicit instructions provided at execution time. -
State
Stored outside the model, in explicit artifacts or system state — not in the model’s memory. -
Role of code
Secondary, optional, or generated for deployment — never the source of truth.
You are not programming code.
You are programming the interpreter of instructions.
A minimal example
## Workflow: Daily Sales Check
- Collect yesterday’s sales data from the payment system.
- If no data is available, STOP and record the reason.
- If total revenue is below the agreed minimum, STOP and flag for review.
- If any transaction looks inconsistent, STOP and request clarification.
- Otherwise, summarize key metrics in plain English.
- Save the summary as `daily-sales-report.md`.
## Workflow: Planning a Team Meeting
- Check the shared calendar for available time slots this week.
- If no common slot exists, STOP and notify the organizer.
- If a slot conflicts with a mandatory event, STOP and explain why.
- Otherwise, propose one concrete meeting time.
- Write the proposal into `meeting-proposal.md`.
These texts are not a prompt for an answer. They are programs that defines admissible behavior.
Vibe Programming vs. Vibe Coding
Both approaches use natural language to accelerate development. The difference is what is treated as the program.
| Aspect | Vibe Programming | Vibe Coding | | ---------------- | ----------------------------------- | ------------------------- | | Primary artifact | Textual protocols | Generated code | | LLM role | Interpreter of instructions | Code generator | | Code status | Optional or derived | Central deliverable | | Structure | Multi-step, explicit, auditable | Iterative, conversational | | State | Externalized in artifacts | Implicit / session-based | | Typical use | Production workflows, orchestration | Prototypes, MVPs | | Main skill | Protocol design | Prompt crafting |
Vibe coding is optimized for speed: describe a feature, generate code, refine, deploy.
Vibe Programming is optimized for governance and continuity: instructions live as durable artifacts that can be reviewed, composed, and enforced.
Why this matters
Vibe Programming lowers the barrier between intent and execution:
- Business logic can be expressed directly, without translation into code first.
- Workflows become inspectable, shareable, and composable.
- Execution is driven by explicit rules rather than inferred intent.
LLMs stop being “answer machines” and become instruction interpreters.
The challenges are real — ambiguous language, protocol quality, interpreter limits — but they are architectural problems, not prompt tricks. With proper constraints and externalized state, the approach becomes reliable and production-capable.
Positioning note
Vibe Programming describes a programming paradigm. Protocolware describes a governance and execution system built on similar principles.
They are related, but not interchangeable.
Vibe Programming answers: “What is the program?”
Protocolware answers: “How is that program governed, admitted, and audited?”
Closing
Vibe Programming reframes software development around a simple idea:
If humans can read the instructions, the system can be governed.
The language becomes the program. The interpreter executes it. Everything else becomes implementation detail.
Next
- “Retries Are a Smell”: /essays/retries-are-a-smell
- “Stopping Is a Feature”: /essays/stopping-is-a-feature
- “Governance Before Execution”: /essays/governance-before-execution
- “Why Artifacts, Not Prompts”: /essays/why-artifacts-not-prompts
- “Vibe Programming: A Protocol-First Paradigm”: /essays/vibe-programming
- “Why There Is No Plan in the Doctrine”: /essays/why-no-plan
- “LAW, GATE, PATH, LOG, STATE — The Five Protocols”: /essays/law-gate-path-log-state-protocols