What vibe coding is

Starting point: a 185-word tweet

On February 2, 2025, Andrej Karpathy wrote this on X [1]:

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. … I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

See stuff, say stuff, run stuff, paste stuff, and it mostly works. That one line became the template for every definition that followed. Sarkar and Drosos call the tweet the "Karpathy canon", and instead of setting a norm they use a single criterion: if you call it vibe coding, it is vibe coding [2]. What actual users say is more candid. They describe letting the AI do the heavy lifting, just chatting with the app, and embracing the AI without digging into the code [2].

The definition is a spectrum

A 2026 multivocal literature review (28 papers + 19 practitioner sources) gathers twelve definitions and merges them into one [4]. In paraphrase:

Vibe coding is an intent-driven development practice. The developer states the desired functionality, constraints and context, mostly in natural-language prompts, and a language model generates, modifies and iterates on the code. The developer's role shifts from writing code directly to expressing intent, evaluating results, asking for fixes, and steering the next iteration. In its strongest form (Karpathy) the code is never read at all, but in practice it sits on a spectrum from minimal review ("pure" vibe coding) to structured verification with tests, linting and human review.

Meske et al. call this a "reconfiguration of intent mediation". In a history running from patch cables through assembly, FORTRAN, object orientation and low-code, it is the first moment when deterministic instruction turns into probabilistic inference [3]. A review of 101 practitioner sources puts it more briefly: a practice that puts speed and experimentation ahead of understanding [5].

The loop

Whatever the definition, what people actually do is the same. A study that analyzed 8 hours and 27 minutes of vibe coding sessions observed this cycle [2]:

1. Set a goal (or sub-goal)
2. Write a prompt
3. Look (roughly) at the generated code
4. Accept or reject it
5. Run the app
6. Find bugs
7. Revise the prompt, or fix it by hand → back to 2

The "roughly" in step 3 is the characteristic part. The programmers in this study did not read the code line by line. They did an "impressionistic scan" of the size and shape of the red and green diff, and sometimes accepted changes of dozens of lines within two seconds [2]. Step 5 is the real review. That is why several papers conclude that what really matters is the rigor of the evaluation loop around generation, more than the speed of generation itself [4].

Expertise moves elsewhere

No paper concluded that expertise is unnecessary because you no longer write code. The evidence points the other way.

• Expertise shifts from writing code toward evaluating, steering and refining AI output [2]. Three kinds of expertise mix: traditional programming, handling AI (models, prompts, context windows), and product management (the ability to decide what to build).
• The human takes the "What" and the "Why", and the agent takes the "How" [7].

• In a survey of 162 people, non-developers, novices and experts reported a similar experience (it looks right but turns out wrong when you run it; good for demos, not for production), but their verification behavior differed. Non-developers were the only group who answered that they never check the generated code, and they were also more likely to give up on debugging because they could not understand it. In the regression analysis, what explained the difference was the accumulated time spent coding on one's own, more than job title [6].

Sarkar and Drosos go one step further. All the vibe coders they observed were skilled programmers, and they write that vibe coding by non-experts may be a quite different activity that only looks similar, and that this has not yet been studied [2]. This wiki's How to do it well is an attempt to fill that gap.

How far to trust it: five models

A survey that went through more than 1,000 papers divides working styles into five models according to how much review takes place [7]. It is a useful yardstick when making work.

Model	What	When
UAM Unconstrained automation	Trust all AI output and barely look at it	Throwaway prototypes, proofs of concept, personal tools, and no further
ICCM Iterative conversational collaboration	AI generates → a person reads and understands → tests → accepts. The AI drives, the person navigates	Most work
PDM Planning-driven	Write three documents first (spec, rules file, implementation plan), then start	Long-running projects
TDM Test-driven	The tests are the spec	Parts where correctness matters
CEM Context-enhanced	Always provide a codebase index, docs and rules files	Combines with any of the above

The prototype you make on the first day can be UAM. The work you install for the December exhibition cannot. The key is to decide in advance which one you are doing before you start.

Vibe coding and agentic coding

This is where the difference between Cursor's "chat" and "agent" modes comes in. Sapkota et al. separate vibe coding (the human as supervisor and co-pilot, working component by component, with the feedback loop outside the system, that is, in the human) from agentic coding (the agent plans, executes and tests, and the human supervises), and expect vibe coding to become the creative front end and agentic coding the back end that runs and scales it [8].

Use case 9 in the same paper is exactly our kind of work: a request for a JavaScript animation that reacts to music and clicks → a p5.js and Tone.js pipeline → make the colors change with the beat strength → add particle trails on click. The authors say this greatly lowers the barrier to generative art, sound visualization and interactive installation [8].

In class

One number

There is an experiment in which experienced developers working with Cursor + Claude became 19% slower [cited in 7]. A good tool does not make you faster by itself. You get faster when you give good context, the environment is set up, and the way of collaborating is settled. Where this way of working is going is covered in Where it is heading, why it is not unfamiliar in Names that already existed, and the "settled way" in How to do it well.