Vibe Coding: When Intent Becomes the Code

From Karpathy’s meme to a real programming paradigm

Image made with Openai

I learned to detect double-clicks the hard way.

Late in the 1980s, on a classic Macintosh, there was no “onDoubleClick” event. If you wanted that behaviour, you measured the time between clicks yourself, compared pixel distances, and manually decided whether two clicks belonged together.

Today I type onDoubleClick in React and move on. Somewhere along the way, the timers and coordinate checks vanished behind an abstraction.

I now see that shift happening again. This time, the layer that is disappearing isn’t pixel logic or event loops; it is the code itself.

I’ve started working in what Andrej Karpathy (jokingly?) called vibe coding: generating code from natural-language descriptions. But I use the term in a more specific way: not just prompting, but maintaining structured specifications using manifests and logbooks, while treating the generated code as a regenerable by-product.

It feels as real as the leap from hand-built double-click detection to event handlers. Another abstraction layer rising.

The next abstraction layer

Every major move in software has been a surrender of control:

• from opcodes to assembly
• from assembly to C
• from imperative code to declarative frameworks
• from manual DOM manipulation to React’s reconciler

Each time, critics claimed the new layer wasn’t “real programming.”, or one gave up control. Each time, the abstraction won. Vibe coding is the next turn of that wheel. The shift isn’t from low-level to high-level code, but from code to intent.

I now maintain:

• a manifest describing what the system must do
• a logbook explaining why it’s designed that way
• and let the code be generated when needed

This leads naturally to a definition:

Vibe coding is programming where the primary artifact is a natural-language specification, and the code is a regenerable implementation detail.

It’s the same pattern as C versus assembly, just one layer higher.

Why this works at all

My background in SQL and Prolog makes this shift feel strangely familiar. In SQL, you describe what you want; the engine decides how. In Prolog, you specify relations; the engine explores the space of proofs. In both cases, the “program” is an intention, not a step-by-step plan.

Vibe coding extends that ideal to general software:

• you describe behaviour
• articulate constraints
• and let the model synthesize a plausible implementation

Write “validate email input,” and the model brings in decades of best practices, standards, typo-patterns, and UX conventions.

Overspecify, and you block this advantage. Underspecify, and you invite chaos.

The art lies in expressing intent at the right altitude.

My current workflow

Working in LLM equipped editors coding, I’ve settled into a simple pattern:

• MANIFEST.md — the behavioural contract
• LOGBOOK.md — decisions and rationale
• CODE/ — regenerated when needed

The manifest is my source of truth. The logbook is my memory. The code is a cache, what can be executed or run.

Colleagues can understand a system by reading two Markdown files. If something breaks, I regenerate the module. It’s fast and conceptually clean.

What it feels like

React introduced a sense of “felt causality”: onClick={open} suggests a causal link from a click to an action that happens immediately, despite the machinery of synthetic events, batching, and reconciliation. The click is mediated, but the mediation is hidden.

Vibe coding moves that feeling one level up: “I describe what I want, and the system behaves accordingly.”

Assembly programmers felt close to the machine. C programmers felt close to the system. React developers feel close to user intent.

Vibe coding simply moves that feeling higher, to intent itself.

Where it breaks

It’s not magic. It fails where:

• requirements are vague
• performance constraints dominate (but the LLM may help)
• precision in data structures is critical
• long-term maintainability requires tight formalism

The same kinds of edge cases where SQL occasionally needs hints and Prolog needs cuts.

What this suggests

Most modern software isn’t real-time simulation or hardware control. It consists of APIs, dashboards, data pipelines, transformations, workflows, interfaces. And most of this can be regenerated from a good manifest, just like most assembly could be produced from a good C compiler.

That leads to a the realization that the code itself might not be the primary object anymore.

We may be heading into a literate phase of programming, where:

• reasoning matters more than syntax
• narrative becomes structure (the what not the how)
• and regeneration replaces manual maintenance

I’m still experimenting, but the pattern is familiar. The abstraction layer keeps rising.

Try it in your next project — 3 steps

1. **MANIFEST.md** – write what the app must do, in clear paragraphs
2. **LOGBOOK.md** – record every decision and take note of issues
3. Regenerate code from the manifest whenever you need it

That’s it. The **/src** folder is now just a cache.