The Starvard sealStarvard.
English
EnglishEspañolBahasa IndonesiaPortuguêsहिन्दीFrançaisAll languages →
Starvard University

The Starvard Blog

Notes from the free university

What Vibe Coding Actually Is, a Year and a Half In

October 18, 2026 · By the Starvard professors
A relaxed coder speaking while blocks of code assemble into an app in the air
Illustration by Starvard (AI)

A throwaway tweet in February 2025 named a whole new way of building software. Here is what the term really means, what the practice looks like day to day, and what the best numbers say about how many people actually work this way.

Most programming terms are born in textbooks or standards committees. This one was born in a post its author later described as a shower thought.

On February 2, 2025, Andrej Karpathy, a founding member of OpenAI and former director of AI at Tesla, published a short post on X. It began: "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."

The post was seen millions of times. Nine months later, Collins Dictionary named "vibe coding" its Word of the Year for 2025. Few technical phrases have ever traveled that fast, from one person's weekend habit to the dictionary. But somewhere along the way, the meaning got loose. Today people use "vibe coding" for almost any programming that involves an AI tool, and that is not what the word was coined to describe. Getting the definition right matters, because the real numbers about this practice are more interesting, and more mixed, than the hype in either direction.

The original post, and its fine print

Karpathy's post is worth reading closely, because he described a specific workflow, not a general attitude. He said he talked to Cursor Composer, an AI coding tool, often using voice input through a tool called SuperWhisper, so he barely touched the keyboard. He asked for, in his words, "the dumbest things," like cutting the padding on a sidebar in half, because he was too lazy to find the setting himself.

Three habits defined the method:

And then came the fine print that later coverage often dropped: "It's not too bad for throwaway weekend projects, but still quite amusing." Karpathy scoped his own idea to projects he could afford to throw away. He also closed with the line that became the movement's motto: "I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

So vibe coding, in the original sense, is not "using AI to help you program." It is building software by describing what you want, accepting what the machine writes, and judging only the running result, without reading the code itself. The code is treated as an output you never inspect, like a compiled binary.

The line that keeps the term honest

Within weeks, developer and writer Simon Willison pushed back on the sloppy usage, in a March 19, 2025 post that remains the clearest definition work anyone has done on the term. His test is simple. If an AI wrote every line of your code, but you reviewed it, tested it thoroughly, and could explain to another person how it works, that is not vibe coding. That is software development with an AI assistant, a much older and more respectable activity.

Under that test, vibe coding is the specific case where review is skipped. The distinction sounds pedantic, but it decides real arguments. When a company says its engineers "vibe code," it might mean anything from careful AI-assisted work with full code review to genuinely unreviewed generation shipped to production. Those two practices have completely different risk profiles, as the security research in our companion post shows.

In practice, AI-assisted building now sits on a spectrum:

Most professional work in 2026 sits in the middle two bands. The ends of the spectrum get the headlines.

How we got here: seventy years of writing less code

To see why vibe coding was even possible, it helps to know what programming looked like before it. Strip away the tools and programming is an act of translation. A human has an intention: charge the customer once, not twice. A computer needs instructions stated in a language so rigid that a misplaced comma can break everything. The whole history of programming is the history of widening the distance between those two poles, so that humans could work closer to the intention and let machines handle more of the translation.

The first programmers wrote close to the metal, in numbers and terse mnemonics, and a program of any size was a physical ordeal. The first great shortcut was the compiler, in the 1950s: write something closer to mathematics and logic, and let a program translate it into machine instructions. Then came friendlier languages, then libraries of prewritten parts, then frameworks that supply the skeleton of a whole application before you write a single line. Each generation kept the same bargain. The human said less. The machine filled in more. And each generation had its purists warning that the new layer would produce programmers who did not understand what sat underneath. Each time, the purists were partly right, and the layer became standard anyway.

A staircase of programming abstraction rising from punch cards to speaking plainly to a computer
Illustration by Starvard (AI)

Two things about the newest layer break the pattern. The old layers were deterministic: the same input always produced the same output, and the rules could, in principle, be read. The new layer is a model that learned from examples, produces somewhat different output each time, and cannot show you its rules, because it does not keep them in any form a human can read. That difference, a translator you cannot audit, is the real subject of everything that follows.

The milestones of this final climb came fast:

Seen against that timeline, the tweet was not the start of something. It was the moment a famous insider admitted in public how far he had personally slid down a slope the whole industry was already on. The surprise was not the technology. It was the permission.

Watch: [1hr Talk] Intro to Large Language Models, from Andrej Karpathy. Recorded in November 2023, it remains the clearest one-hour explanation of what ChatGPT actually is, from the same person who would name vibe coding fifteen months later.

Under the hood: why the machine can do this at all

People often ask the wrong question about these tools: how does it know how to program? The honest answer is simpler and stranger. It does not know, in the way a person knows. It predicts.

A large language model is trained on an enormous library of text, including, for coding models, a large share of the public code on the internet: open source projects, tutorials, documentation, question and answer threads, bug reports and their fixes. In training, the model plays one game billions of times: given everything so far, guess the next small chunk of text, a token, which is roughly a piece of a word. It is graded on the guess, adjusts itself slightly, and plays again. Nobody hands it rules. What all that guessing builds is a system with an extremely refined sense of what usually comes next.

Code turns out to be one of the best possible subjects for that game. Programming languages have strict grammar, far stricter than English. Programmers reuse the same patterns millions of times: connect to the database, check the password, show an error if it fails. A large share of real world code is a variation on something that already exists somewhere. So when you ask for a login page, the model is not inventing the login page from first principles. It is producing the statistical center of all login pages, assembled from more examples than any human could read in a thousand lifetimes.

Watch: Large Language Models explained briefly, from 3Blue1Brown. Made for the Computer History Museum, it animates this prediction game in about eight minutes, and it is the friendliest visual version of the idea anywhere.

That single fact explains both the magic and the failure modes, so it pays to be precise about what the model does not have:

None of this makes the tool useless. It makes it a specific kind of useful: a tireless producer of strong first drafts at a speed no human can match, whose work still needs the one thing it cannot supply for itself, verification by someone, or something, that actually ran the code and checked what it did.

A vibe coding session, step by step

Definitions only go so far. Here is what the practice actually looks like from the chair, in one illustrative session of the kind thousands of people now run every evening. Picture Maya, who runs a small after school tutoring business: six tutors, about eighty students. Her enrollment lives in a spreadsheet, her invoices live in her head, and both are starting to slip. She has never written code. On a Tuesday night she opens an AI builder and types what she would say to a person: "Build me a simple app to track my students, their weekly sessions, and who has paid. I want this month's unpaid invoices on the first screen."

A small business owner at her kitchen table as her words become a working app
Illustration by Starvard (AI)

Step one: the build. Within a couple of minutes the tool produces the skeleton of a small web application: a page for students, a page for sessions, a database with a table for each, and a dashboard showing unpaid invoices. She did not choose the framework, the database, or the layout of the files. Those decisions were made for her, silently, when the model picked the most common way such apps are built. This is the first thing to understand about the session: dozens of real engineering decisions have already happened, and the vibe coder was not present for any of them.

Step two: the first run. She clicks preview and the app appears. It looks like software: a clean table, working buttons, her three test students listed neatly. This moment, the leap from one sentence to a running thing, is the experience that converts skeptics. Nothing in the previous seventy years of tooling gave a non-programmer this moment.

Step three: the steering. Now the sustained work begins, and it is worth noticing what kind of work it is. "Sort the unpaid list oldest first." "Add a button that texts a reminder." "Exam prep sessions cost more." Every instruction is a product decision, stated in the language of her business. Without the title, she is doing the job of a product manager: deciding what the software should do, in what order, and what right looks like. The typing she is not doing was never the whole job of building software. It was just the part that used to lock her out.

Step four: the error loop. The reminder button breaks the page. She copies the red error text, pastes it back with "it broke," and the model apologizes, changes three files, and the page works again. She does not know what was wrong, or what changed. Karpathy described exactly this loop in his original post, and it works surprisingly often, because a large share of beginner errors are common errors, with common fixes well represented in the model's reading.

Step five: the wall. Then she asks for something her business genuinely needs: partial refunds for cancelled sessions, split across two payment methods. The model produces code that looks exactly as confident as everything before it. The totals are subtly wrong. She asks again; it fixes one case and breaks another. This is the moment every long session eventually reaches. The problem lives in the atypical core of her business, which is where the model is weakest, and she has no way to inspect the machinery. Her options are the ones Karpathy listed: work around it, keep asking for changes, or simplify the requirement until the model can hold it.

Step six: the bill and the risk. By Friday, Maya has a tool she uses every day, built across a few evenings, instead of a contractor's quote she could not have paid. She also has an application holding real customer data, whose security she cannot evaluate, whose backups she has not thought about, and which exactly one intelligence on Earth has ever read, and it does not remember reading it. Both halves of that sentence describe the true state of vibe coding in 2026. The skill is knowing which half you are standing in at any given moment.

What the adoption numbers actually say

The biggest annual snapshot of the profession is the Stack Overflow Developer Survey. The 2025 edition drew responses from more than 49,000 developers in 177 countries, and its AI findings describe a field that has adopted the tools almost completely, while keeping its guard up.

What developers told Stack Overflow in 2025 Use AI tools, or plan to 84% Say vibe coding is not part of their work 72% Frustrated by "almost right" answers 66% Use AI tools daily (professionals) 51% Distrust AI output accuracy 46% Trust AI output accuracy 33%
Source: Stack Overflow Developer Survey 2025, AI section, more than 49,000 respondents.

And here is the number that complicates the vibe coding story most: when the survey asked developers directly whether vibe coding was part of their professional work, 72% said it was not, with another 5% emphatic about it. Read together, the survey describes a profession that uses AI constantly but mostly refuses to skip the review step. The tools won. The pure vibes, at work, mostly did not.

A second large research program tells the same story from the organization's side. DORA, Google's long-running study of software delivery, devoted its 2025 report to AI-assisted development and surveyed nearly 5,000 technology professionals. It found that 90% now use AI at work, spending a median of two hours a day working alongside it. More than 80% said AI had raised their productivity, yet 30% said they trust the code it generates little or not at all, a pairing the researchers call the trust paradox. And for a sense of the installed base: GitHub reported that Copilot alone passed 20 million users in July 2025. Tens of millions of people now work with AI-written code daily. By every survey we have, only a small minority of them are willing to skip reading it.

The sharp exception is the startup world. In March 2025, Y Combinator managing partner Jared Friedman revealed that a quarter of the startups in YC's Winter 2025 batch had codebases that were 95% generated by AI. He stressed that these were not beginners cutting corners: "Every one of these people is highly technical, completely capable of building their own products from scratch. A year ago, they would have built their product from scratch, but now 95% of it is built by an AI." YC president Garry Tan went further: "This isn't a fad. This isn't going away. This is the dominant way to code."

Even inside YC, though, the caveat survived. Partner Diana Hu argued that good vibe coding still requires judgment: "You have to have the taste and enough training to know that an LLM is spitting bad stuff or good stuff."

Year two: the word settles, the practice grows up

Three moments mark how the idea matured after its viral spring. In June 2025, Karpathy gave the keynote at Y Combinator's AI Startup School, framing vibe coding inside a larger shift he called Software 3.0, in which natural language becomes a programming interface. "LLMs are a new kind of computer," he told the audience, "and you program them in English." His chapter on vibe coding carried a telling title: "Everyone is now a programmer."

In November 2025, Collins Dictionary made it official, defining vibe coding as "the use of artificial intelligence prompted by natural language to assist with the writing of computer code." Collins' managing director Alex Beecroft said the choice "signals a major shift in software development, where AI is making coding more accessible."

Then, in February 2026, around the one-year anniversary of the original post, Karpathy proposed a successor term for the professional version of the practice: agentic engineering. The idea, as reported at the time, is that the default is no longer writing code yourself but orchestrating agents who write it, while you act as oversight. The word "engineering" was chosen on purpose, to insist that there is art, science, and expertise in doing it well. The man who told the world to forget the code exists spent the following year explaining, in effect, when to remember it.

That arc is the honest summary of vibe coding a year and a half in. As a doorway, it is historic: people who never wrote a line of code are building working software, and experienced builders are producing in days what used to take weeks. As a discipline, the pure form is a starting point, best suited to prototypes, personal tools, and projects whose cost of failure is low. The grown-up version keeps the speed and restores the review. Knowing which mode you are in, and choosing it on purpose, is the real skill the term now points at.

The case against, taken seriously

No account of this practice is complete without the critics, because several of their arguments are simply right.

"It is just prototyping with better marketing." Partly true. Throwaway prototypes are decades old, and every generation of tools, from Visual Basic forms to website builders, let non-specialists produce working demos. What actually changed is the finish line illusion. Older prototypes looked like prototypes, gray boxes and dead buttons, so nobody shipped one by accident. An AI-built prototype looks finished, behaves in the demo, and cheerfully invites you to take payments through it. The new risk is not that the tool exists. It is that the prototype's disguise got perfect. Our companion post documents what happened to some of the people who shipped the disguise.

"It eats the ladder." Programming judgment was historically built by writing enormous amounts of bad code and debugging it at 2 a.m. If the machine writes the first draft of everything and fixes its own errors when pasted back, beginners get far less of the struggle that produced senior judgment, the same judgment Diana Hu says you need in order to tell good output from bad. The optimistic reply is that the struggle moves up a level, from syntax to systems. The honest reply is that nobody knows yet, and the first generation that will find out is already in the workforce.

"The word itself is marketing." Tool vendors benefit when skipping review sounds like a lifestyle rather than a risk decision, and a playful name helps sell that. Notice who profits from fuzziness. If "vibe coding" can mean everything from supervised agent work with full review to unreviewed generation in production, then the safest practice and the riskiest one share a fun brand, and the riskiest one borrows the safest one's respectability. Willison's definition work matters precisely because it refuses that fuzziness.

Set against all three arguments is the door itself, which is real. People who were locked out of building software by years of syntax are now making working tools for their own businesses, classrooms, clinics, and families. That has never happened at this scale, in all of computing history, and it is not going back. The argument worth having is not whether the door should exist. It is what a person should learn before walking through it carrying other people's data.

Why this belongs at Starvard

Starvard exists to teach the skills that are actually changing how people work, and few changes are bigger than this one. If you want to understand the technology underneath the trend, start with our AI course, which explains what large language models are and how people use them well. If you want to build the judgment Diana Hu talks about, the fastest route is still learning to read code, and our Python course is the friendliest place to begin. And if your interest is the products themselves, our Web Design course covers how the things vibe coders ship actually reach people's screens. The vibes are free. The understanding is the part worth studying.

Watch

Sources

Back to the blog

A note on accuracy: Much of what you read at Starvard was created with help from AI agents, working alongside people. We check what we can, but we cannot guarantee that everything here is true, current, or complete. If something really matters, your health, your money, a grade, a job, please verify it with a trusted source before you rely on it.