The Rise of Vibe Coding
What happens when programming stops being about logic and starts being about feeling? A look at the movement that is rewriting who gets to build software.
There is a moment every developer knows. You open a blank file, stare at the cursor, and try to translate a fuzzy idea in your head into a precise sequence of instructions a machine will obey. It is humbling and often frustrating. Now imagine skipping almost all of that. Imagine just… feeling your way through.
That is the promise — and the provocation — of vibe coding.
What is vibe coding, exactly?
The term was coined in early 2025 by AI researcher Andrej Karpathy, who described a workflow where you “fully give in to the vibes” and let a large language model write almost all your code. You describe what you want in plain language, review the output loosely, accept it, and keep pushing forward without reading each line carefully. The human becomes the curator, the director — not the typist.
“It’s not really coding. It’s more like conducting. You set the intention, and the model fills in the notes.”
Vibe coding is not simply using GitHub Copilot to autocomplete a function. It is a full philosophical shift: from code as craft to code as output. The programmer’s job is to hold a clear mental model of what should exist, communicate that to an AI, iterate rapidly, and ship.
Why now?
Models like Claude, GPT-4o, and Gemini have reached a threshold where they can write coherent, functional multi-file applications with minimal hand-holding. Token context windows have grown large enough to hold entire codebases. Tools like Claude Code, Cursor, and Devin can autonomously run tests, read error messages, and fix their own bugs.
The gap between “having an idea” and “having a working prototype” has collapsed from weeks to hours. For many founders and product thinkers, that gap was the barrier. Now the barrier is almost gone.
Who is vibe coding for?
It’s attracting two very different crowds: non-technical founders who want to build MVPs without hiring engineers, and experienced developers who want to move 10× faster on exploratory or side projects. The common thread is impatience with friction.
The criticisms are real
Not everyone is enthusiastic. Senior engineers have raised legitimate concerns: code produced through vibe coding is often fragile, poorly structured, and difficult to maintain. When you do not fully understand what was written, debugging becomes archaeology. Security vulnerabilities can slip through unnoticed. Technical debt compounds invisibly.
There is also a subtler worry. Programmers build intuition over years of close contact with code — understanding why something fails, recognizing patterns, anticipating consequences. Vibe coding may produce outcomes without cultivating understanding. The question is whether that matters for every use case.
“The model doesn’t know what it doesn’t know. And neither do you, if you never read the code.”
The honest answer: it depends on what you’re building
A weekend project that scrapes data and sends you a summary? Vibe code it. A payment processing system handling real user funds? Probably not. The approach scales with the stakes and the expected lifespan of the software. Throw-away tools, internal dashboards, prototypes, creative experiments — these are natural homes for the vibe.
Interestingly, many experienced developers are adopting a hybrid approach. They vibe code the first draft, then review, refactor, and harden the parts that matter. The AI becomes a scaffolding tool, not a replacement for engineering judgment.
A new literacy?
Perhaps the most interesting consequence of vibe coding is not what it does to software quality, but what it does to who makes software. The act of building an application used to require fluency in at least one programming language, familiarity with debugging tools, and some mental model of how computers work. Those requirements are eroding fast.
Designers are shipping fully functional products. Writers are building their own publishing tools. Scientists are automating their own workflows without waiting for an engineering team. The population of people who can realistically say “I could build that” has exploded.
Whether this is democratization or dilution depends on your values. Probably it is both, at the same time, in different places.
· · ·
Vibe coding will not replace software engineering. But it is already reshaping it — expanding who participates, compressing how long things take, and forcing a reckoning with what programming was actually for. If the goal was always to make something work, then the vibe might be enough. If the goal was understanding, then the vibe is only the beginning.
Either way, the cursor is no longer as intimidating as it used to be.
