Blog
What is vibe coding, and why it matters even if you never write a line of code
Vibe coding changes who gets to build software. Here's what it actually is.
On this page
Vibe coding is building software by describing what you want and letting an AI write the code. The name comes from Andrej Karpathy, who used it in early 2025 for a way of working where you "forget that the code even exists" (Karpathy, 2025): you say what you want, accept what comes back, run it, and steer by results. If that sounds too casual to produce anything real, that reaction is exactly why the term needs a proper explanation.
Most explanations focus on the magic: you describe what you want, AI writes the code, you ship something real without ever touching a terminal. That part is true. What those explanations skip is the more interesting edge: vibe coding lowers the barrier for beginners, and it changes what experienced people build too.
What it looks like in practice
Here is the before and after I see most often in the workshops I run.
Before: someone has an idea, say a tool that takes the weekly rota their team keeps in a spreadsheet and turns it into a shareable calendar. To get it built they need a developer, a budget, and a slot in someone's backlog. The idea is small, so it never clears that bar. It stays a spreadsheet and a standing complaint.
After: the same person opens an AI coding tool and types roughly what they would have written in the request ticket. "A page where I paste our rota and it gives everyone a calendar link." The first version appears in minutes and is wrong in obvious ways, so they say what's wrong, in plain language, and the next version is closer. An afternoon later they have something their team actually uses. Nobody was hired. Nothing was scheduled. The gap between having an idea and having a working thing collapsed from months to hours.
That collapse is the whole point. Not that the code is brilliant (it usually isn't), but that trying an idea became cheap enough to do on a whim.
Who it's for
The obvious audience is people who never learned to code: designers who want their prototypes to work rather than pretend to, researchers who need a custom tool no one will ever build for them, founders who want to test the idea before paying anyone. For that group, vibe coding is the difference between building and waiting.
The less obvious audience is developers. The ones I know who work this way spend far less time on boilerplate and glue code, and far more on the parts that need actual thought: what to build, how the pieces fit, whether the result holds up. Knowing syntax matters less than it did. Knowing what to ask for, and recognising when the answer is wrong, matters more.
The honest limits
Vibe coding earns its casual name at the prototype end, and you should treat the confidence of its output the way you'd treat any fluent AI output: as unverified until checked.
The code works until it doesn't, and when it doesn't you're debugging something you didn't write and may not understand. That's fine for a rota tool. It is not fine for anything handling money, health data, or other people's passwords. If real users or real stakes are involved, someone who understands the code needs to look at it, and "the AI said it's secure" is not that.
There's also a difference between a thing that runs and a thing that lasts. Prototypes rot: dependencies age, edge cases pile up, the one person who prompted it together forgets how it works. Vibe coding gets you to a working version fast; keeping software alive is still engineering, whoever does it.
None of this is an argument against the practice. It's an argument for knowing which mode you're in. A weekend hack can be pure vibes. A product needs the vibes plus review, tests, and someone accountable for the result.
Why it matters beyond the people doing it
Even if you never build anything yourself, the people around you now can. Colleagues will show up with working tools instead of feature requests. Small internal problems that never justified a developer will quietly get solved, and some fraction of those tools will grow into things a business depends on, which is when the limits above stop being theoretical. Knowing what vibe coding is, and what it is not, is becoming part of basic software literacy, the same way knowing what a spreadsheet can and can't do already is.
If you want to go deeper (guides, tool comparisons, real projects, and a community building things this way in Finnish), head over to vibekoodaus.fi.
Sources
Karpathy, A. (2025, February 2). There's a new kind of coding I call "vibe coding" [Post]. X. https://x.com/karpathy/status/1886192184808149383
Related posts
How a language model actually works: one trick, taken very far
Underneath the chat window, a language model does one thing: guess the next token. How that single trick, scaled far enough, turns into something you can talk to, and the honest argument over whether any of it counts as understanding.
11 min readSpotting AI hallucinations: a practical checklist
How to catch confident-but-wrong AI output before it bites you. A short, practical checklist plus the reason hallucinations happen in the first place.
5 min readVibe research, explained (and why I'm optimistic)
Vibe research means you set the direction and AI agents do the execution, while the judgement and accountability stay yours. What it is, why I'm optimistic, and the failure mode to watch for.
9 min read