In early February 2025, AI researcher Andrej Karpathy posted a few casual sentences on X describing a new kind of coding where the builder gives in to the vibes and forgets the code even exists. Within a year the phrase had a dictionary entry, a job title, and millions of practitioners, many of whom had never written a line of code.

The origin story matters because the term's meaning got stretched almost immediately. The founding post scoped vibe coding to throwaway weekend projects, and the internet dropped that fine print as the phrase spread. Anyone building with AI today inherits both the promise and the confusion.

This lesson traces the term from its origin to its dictionary canonization, weighs the evidence on who's building and how fast, and takes on the biggest myths, including the claim that vibe coding is already dead.

What is vibe coding?

Vibe coding is building software by describing the desired outcome in plain language and letting an AI model write the code, without reading the code it produces. Andrej Karpathy, an OpenAI co-founder and former Director of AI at Tesla, coined the term in a post on X in early February 2025: "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." [1]

The post described the practice concretely. Karpathy talked to his coding tool by voice, accepted every suggestion without reading the changes, and pasted error messages back in without comment. He summed up the loop as "I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works." [2]

The defining move isn't using AI; it's surrendering code review. Simon Willison later drew the line sharply: if the builder reviews the code, tests it thoroughly, and can explain how it works, "that's not vibe coding, it's software development." [3] Vibe coders judge the running result instead, and that distinction shapes everything else in this course.

The founding post's fine print

The limitations of vibe coding weren't discovered later; they were written into the founding post itself. Karpathy scoped the practice to "throwaway weekend projects" from day one, noting that when the AI couldn't fix a bug he would simply "work around it or ask for random changes until it goes away." [4]

The internet stripped that qualifier as the term spread. Within months, media coverage applied vibe coding to everything from quick prototypes to production systems, and the modest original scope disappeared from the conversation. In his one-year retrospective, Karpathy called the original post "a shower of thoughts throwaway tweet" and noted he couldn't have predicted its reach. [5]

Reading the fine print now saves grief later. The inventor documented the limits before the hype existed, so builders who honor the original scope, quick experiments rather than finished products, start with realistic expectations.

From tweet to dictionary

On 6 November, 2025, Collins Dictionary named vibe coding its Word of the Year, defining it as the use of AI prompted by natural language to help write computer code. Collins managing director Alex Beecroft explained the choice: "It signals a major shift in software development, where AI is making coding more accessible." [6] CNN, Euronews, and Time all covered the announcement. [7]

The timeline is the remarkable part. The term went from a casual post to dictionary canonization in roughly 9 months, a speed that reflects how quickly the practice itself spread through tools, teams, and mainstream culture.

Dictionary recognition matters for a practical reason: it marks the word as a permanent part of the language rather than passing slang. Institutions that track how people actually speak ratified a cultural shift in who gets to build software.

The adoption-trust gap

The adoption-trust gap

The adoption-trust gap is the defining statistic of the AI coding era: nearly everyone uses the tools, and few trust what they produce. Recurring industry surveys, including JetBrains' AI Pulse and Stack Overflow's developer survey, report that roughly 90% of developers use AI tools regularly while only about 29% express trust in the output.

The surrounding numbers tell the same story of scale. Industry analyses estimate that roughly 41% of new code globally is AI-generated, survey data suggests around 63% of vibe-coding-tool users aren't developers, and Replit has reported that 75% of its own users never write code. Methodologies vary across these reports, so they work as directional signals rather than precise measurements.

The gap itself is the durable lesson. Adoption soared because the tools deliver; trust lagged because the output still needs human judgment. Closing that gap, learning when to trust a result and how to check it, is what the rest of this course teaches.

Non-coders building in minutes

Speed stories from named non-coders anchor the vibe coding moment. Wharton professor Ethan Mollick asked a coding agent to "make a 3D game where I can place buildings of various designs and then drive through the town i create" and had a working application in about 4 minutes. [8] When he got bored, he asked for a fire truck and burning buildings, and the tool added traffic and fires on its own.

The pattern extends well beyond demos. Mollick's experimental MBA class on "vibefounding" had non-coders launching working products in 4 days, work he assessed as previously taking a semester, and at higher quality now. [9] New York Times columnist Kevin Roose, not a professional coder, built a lunch-suggestion app that worked from his fridge contents. The practice even became a job title: Lovable employed a "professional vibe coder" who ships production software entirely through AI tools. [10]

For product teams, this is already routine. Per Lenny's Newsletter coverage, it's now more common than not for teams to prototype ideas in AI tools before involving engineers. [11] A researcher, an academic, a journalist, and entire product teams all build the same way: describe the outcome, react to the result, repeat.

The effortless myth

The word "vibe" plus 4-minute demo stories created a persistent myth: the AI does the work, and the human just watches. Experienced practitioners describe the opposite. As reported from the LangChain Interrupt conference in June 2025, AI researcher Andrew Ng called that framing misleading, describing coding with AI as "a deeply intellectual exercise" that leaves him "frankly exhausted" after a full day.

Mollick offers the sharper formulation: vibe coding doesn't eliminate expertise but redistributes it, shifting effort "from writing every line of code to knowing enough about systems to guide, troubleshoot, and evaluate." [12] The typing is delegated; the thinking isn't.

That reframe matters for anyone starting out. Builders supply the direction, the judgment about what counts as good, and the persistence to keep iterating when results miss. Sessions feel like real work because they are real work, just a different kind.

Pro Tip! A mentally tiring session is a sign the process is working; the effort has moved from typing to deciding.

Throwaway first, product later

Vibe-coded output looks finished from the first minute: real interface, real interactions, no visible seams. That polish is the trap. Nielsen Norman Group's research on AI prototyping found the results "good from afar, but far from good," polished in appearance but not contextually right, because the tools pattern-match toward the most common solutions rather than the ones a specific situation needs. [13]

Real failures back this up. Roose's experiments produced an e-commerce demo where the AI fabricated fake product reviews, and security firm Veracode's 2025 analysis reported that roughly 45% of AI-generated code samples introduced common vulnerabilities.

The founding scope doubles as the right starting posture: treat first builds as throwaway experiments, not products. A prototype that proves an idea in an afternoon is a genuine win; the same build treated as a product skips the validation, testing, and hardening that products need.

Pro Tip! A build counts as a prototype until someone other than its maker has used it successfully.

Should beginners learn code first?

For decades, the advice was sound: learn to code before trying to build software. Vibe coding moved the floor that advice stood on. Karpathy frames the change as floor versus ceiling: vibe coding raises the floor, letting almost anyone start building, while software engineering raises the ceiling of what's possible to build. [14]

The evidence for the lower floor is concrete. Mollick's MBA students, none of them coders, launched working products in 4 days. [15] They didn't learn syntax first; they learned to describe outcomes, evaluate results, and iterate.

The real question is what kind of learning still pays off. Concepts help immediately: knowing what a database stores or what an API connects makes prompts sharper and debugging faster. Syntax memorization no longer gatekeeps the starting line, and a later lesson in this course covers exactly which concepts return the most value.

Is vibe coding already dead?

By 2026, the term's own coiner had moved on. Karpathy declared vibe coding passé and shifted his attention to "agentic engineering," a more deliberate practice aimed at professional work. [16] Press coverage noted that he largely hand-coded his own nanochat project, which critics read as the inventor abandoning his invention. [17] Others argue the successor practice was never new at all; Lean UX co-author Jeff Gothelf contends that specifying intent and evaluating outcomes is what product managers have always done. [18]

The obituary is premature for a structural reason: the floor-and-ceiling framing keeps vibe coding valid at the floor, exactly where newcomers start. [19] The practice's population keeps growing even as its label ages, and Collins had already fixed the word in the dictionary. [20]

The takeaway for this course: treat vibe coding as a historical marker with a live practice attached. Terms outlive their coiners' affection all the time; what matters is that the capability, non-programmers building working software, isn't going anywhere.