Vibe Coding

Karpathy used the expression publicly on 2 February 2025 while describing experimental programming in which he accepted generated changes, reported errors back to the model, and sometimes ignored the underlying code. A later empirical preprint by Advait Sarkar and Ian Drosos examined recorded sessions and found a more varied practice: participants alternated prompting, rapid inspection, testing, and manual edits. Collins selected the expression as its 2025 Word of the Year, evidence of lexical adoption rather than proof of one settled engineering method.

Sources: s1, s2, s3

The practice changes where effort and skill are applied. Producing syntax can become less central, while specifying intent, supplying context, evaluating behavior, debugging, and deciding when to inspect or rewrite code become more important. It can lower the barrier to prototypes and small tools, but fluent generation can also conceal defects and create technical debt or maintenance costs. For skills analysis, the useful distinction is therefore not human coding versus machine coding; it is how responsibility moves across specification, generation, verification, and ownership of the deployed result.

Sources: s1, s2

A designer asks an AI coding tool to create a small event page, tests the page in a browser, pastes an error message into the conversation, and requests visual changes without reading every diff. That fits the narrow vibe-coding pattern. If the same person reviews the architecture, inspects generated changes, writes tests, and approves a controlled release, the workflow is better described more broadly as AI-assisted development. The boundary depends on the person's relationship to the generated implementation, not on which product produced it.

Sources: s1, s2

Evidence about the practice is recent, and one preprint based on curated recorded sessions cannot establish typical outcomes across developers, tools, or codebases. The label can also obscure differences between a disposable prototype and software that must remain understandable and maintainable over time. Teams should evaluate generated code according to the consequences of defects, preserve review and testing where failures matter, and avoid treating a successful demonstration as evidence of maintainability.

Sources: s2