Vibe Coding: When Programmers Stop Reading Their Own Code

01 What Vibe Coding Is

Vibe coding is software development in which the developer describes a project or a task in a prompt to a large language model, which then generates the source code automatically. The defining trait is not the use of AI but the posture toward the result: the developer may accept the generated code without thorough review, guiding the work through follow-up prompts and by reacting to what the program does rather than by reading what the program is. The name, half joke and half diagnosis, captures the shift from writing code to steering it.

It is worth being precise about the boundary. Using an AI assistant to draft a function and then reviewing, testing, and owning that function is ordinary AI-assisted development, and it is now close to standard practice. Vibe coding begins where the review stops: the developer trusts the output because it runs, refines it conversationally when it misbehaves, and moves on. The distinction matters because almost everything that is genuinely risky about the practice lives on the far side of that line.

02 Where the Term Came From

The term was coined by Andrej Karpathy, the AI researcher and OpenAI co-founder, in a public post in February 2025. His description was disarmingly personal: he spoke of giving in to the vibes, forgetting that the code even exists, and letting the model handle the details while he nudged the output toward what he wanted. The post was informal, but it landed on a precise observation, that a large language model could write usable code and that a working programmer could plausibly operate without reading it.

The phrase spread unusually fast for a piece of programming slang. Within weeks it was appearing in mainstream technology coverage, in vendor marketing, and in conference talks, and within months it had been absorbed into general business vocabulary. That speed is itself informative. The term gave a name to a behavior that many developers were already drifting into as AI coding tools improved, and naming it made the practice discussable, both by its enthusiasts and by its critics.

03 How the Workflow Actually Runs

In practice, vibe coding works as a loop. The developer describes a change or a feature in ordinary language. The model produces a code diff, sometimes across several files. The developer runs the result, and if it works, accepts it and moves to the next prompt; if it fails, pastes the error back into the conversation and asks for a fix. The review step, the part of traditional development where a human reads every line before it merges, is compressed into a glance at observed behavior.

The economics of the loop explain its appeal. Each individual iteration costs seconds, so the developer experiences a fast, fluid rhythm that traditional edit-compile-debug cycles cannot match, especially for unfamiliar languages or frameworks where the model's fluency exceeds the developer's own. That same fluidity is what makes the loop dangerous: nothing in the workflow inherently distinguishes a correct result from a plausible one, and the developer's ability to tell them apart shrinks with every accepted-but-unread generation.

04 What the Productivity Evidence Shows

The measured record is more modest than the enthusiasm suggests. GitHub's published research on AI-assisted development, including its controlled study with its Copilot coding assistant, reported that developers using the assistant completed a representative coding task significantly faster than the control group, on the order of a 55 percent speed improvement on that specific benchmark task. That is a real finding, and it is a task-level finding. It measured how quickly a developer completes a defined exercise with help, not how quickly a team ships reliable software over a year.

Other strands of evidence point in the same direction with the same limits: developers self-report time savings on routine work such as boilerplate, tests, and translations between languages, while showing weaker gains on architecture, novel algorithm design, and code that must satisfy subtle constraints. The honest summary is that AI assistance reliably accelerates the production of code, and that vibe coding extrapolates from that acceleration an assumption nobody has demonstrated, that the production of code was the bottleneck of software quality in the first place.

05 The Risks of Unread Code

The risks of shipping code no one has read are old risks wearing new clothes. Security is the most discussed: generated code has been publicly demonstrated to include vulnerable patterns, hardcoded secrets, and plausible-looking calls to dependencies that do not exist or behave differently than assumed, and a developer who does not read the output cannot catch any of it at the moment of creation. Maintenance follows the same logic. A codebase no team member fully understands is expensive to change, and the cost compounds as unread generations stack up.

The subtler category is correctness of intent. A model can produce code that passes every visible test while implementing a subtly wrong behavior, the kind of flaw a careful reviewer catches by reading and a vibe-coded workflow catches only after it fails in production. There is also a skills question that experienced engineers raise with some urgency: developers who never read code stop building the internal map of how systems work, which leaves them less capable precisely when the AI assistance runs out, on the novel, high-stakes problems where reading skill matters most.

06 Where It Works and Where It Fails

The evidence and the failure stories sort cleanly by context. Vibe coding works best for low-stakes, self-contained artifacts: throwaway prototypes, weekend projects, internal tools with few users, scripts where the cost of failure is a few minutes. It is telling that the most celebrated vibe coding stories, personal apps built in an evening, small utilities, demos, are almost all in this category, and that the failures that make the news, exposed databases, leaked credentials, production outages traced to unreviewed generated code, are almost all attempts to run the same playbook on systems other people depend on.

The dividing line is accountability rather than technology. When the developer is the only user, unread code is a personal risk. When strangers rely on the output, unread code becomes a liability with security, privacy, and financial dimensions. Nothing about the technique changes across that line; only the cost of being wrong does. This is why the strongest practical guidance from both proponents and skeptics converges on the same rule: vibe code the prototype, then treat whatever survives as a prompt to rewrite or review properly before it matters.

07 Limits of the Current Debate

Both sides of the argument overstate what is known. The enthusiastic case leans on task-level productivity studies and extrapolates them to whole-engineering-team outcomes, which the studies do not measure. The skeptical case leans on anecdotes of failure and treats every unread line as a latent incident, which overweights the visible failures and underweights the countless uneventful prototypes that never touched anything important. Neither posture is supported by long-horizon data, because the practice is simply too young for long-horizon data to exist.

There are also questions the debate has not really engaged. How does vibe coding reshape the profession, given that the skills it bypasses, close reading and mental execution of code, are also the skills that make a good reviewer, debugger, and architect? What happens to liability when the code's author is a model and its accepter is a person who never read it? These questions are being worked out in practice, project by project, rather than decided in advance by the industry.

08 Outlook

The most likely future is not a verdict but a sorting. As models improve, the share of code that can be safely accepted with light review will grow, and the boundary between what may be vibe-coded and what must be read will shift outward rather than disappear. The practices most likely to persist are the boring ones: generated code under test coverage, dependency scanning and secret detection in the loop, and a clear organizational rule about which systems are allowed to be built this way.

The durable insight in Karpathy's half-joking post is that programming is changing from the act of writing instructions to the act of specifying and checking them. Whether that change produces a generation of faster builders or a generation of systems nobody understands is not a property of the technology. It is a property of where individual developers and organizations decide to place the line between trusting the vibes and reading the code, and that line is still theirs to draw.