New vibe coding definition just dropped! "Vibe-Coding is a dialogue-based coding process between a human and an AI where the human guides and the AI implements."
I remain a Karpathy originalist: I still define vibe coding as where you don't care about the code being produced at all. The moment you start reviewing the code you're not vibe coding any more, by the definition I like.
My wife used the $20 claude.ai and Claude Code (the latter at my prompting) to vibe-code an educational game to help our five-year-old with phonics and basic math.
She noticed that she was constantly hitting token limits and that tweaking or adding new functionality was difficult. She realized that everything was in index.html, and she scrolled through it, and it was clear to her that there was a bunch of duplicated functionality.
So she embarked on a quest to refactor the application, move stuff from code to config, standardize where the code looks for assets, etc. She did all this successfully - she's not hitting token limits anymore and adding new features seems to go more smoothly - without ever knowing a lick of JS.
She's a UX consultant so she has lots of coding-adjacent skills, and talks to developers enough that she understands the code / content division well.
What would you call what she's doing (she still calls it vibe coding)?
"Vibe architecting" or maybe less pretentiously, "vibe orchestrating". I think that nicely encompasses thw workflow and required skillset. A very knowledgeable eng can orchestrate all the way but clearly nocode people are able to do this as well.
I think orchestration may be a step that can't really be magicked away by advancements, beyond toy implementations. Because at the end of the day it is just adding specific details to the idea. Sure, you can YOLO an idea and the LLMs can get better at magically cleaning things up, but the deeper you go the larger the drift will be from the concept and the reality without continued guidance.
If LLMs could construct buildings you might describe what you want room by room and the underlying structure will need to be heavily revamped at each addition. Unless you start with "I am making a 20 floor building" you are going to waste a lot of time having the LLM re-architect.
I think the real new skill people are going to get scary good at is rapid architecting without any strong awareness of how things work underneath the hood. This is the new "web programming isn't real programming" moment where future developers might not ever look at (or bother learning about!) variables or functions.
I mean this out of genuine curiosity, not as criticism: did she consider telling claude code to look for any duplicate functionality and remove it? Or even edit CLAUDE.md to tell it to check for duplicates after major refactors and remove them? I use CC every day at the moment and I would expect these sorts of instructions to work extremely well, especially in what appears to be relatively small codebase.
Nah, we need defined levels like for autonomous driving. Level 5 is live deployment of a change where a business need was discovered by AI, the change specified and planned by AI, implemented by AI, and reviewed by AI. Vibe coding (without reading) would be even lower, as a human is in the loop.
I used to work with a guy who double-checked the machine code generated by assembler (he was an old mainframe programmer, and allegedly used to work on a linker for ES EVM).
So, clearly, almost nobody does that anymore. So according to Karpathy's definition, we have all been vibe coding for quite time now. (An aside - if AIs were any good, they would just skip human languages entirely and go straight to binary.)
So I think the "vibe" in vibe coding refers to inputting a fuzzy/uncertain/unclear/incomplete specification to a computer, where the computer will fill in details using an algorithm which in itself is incomprehensible for humans (so they can only "feel the vibes").
Personally, I don't find the fuzziness of the specification to be the problem; on some level it might be desirable, having a programming tool like that. But the unpredictability of the output is IMHO a real issue.
> So, clearly, almost nobody does that anymore. So according to Karpathy's definition, we have all been vibe coding for quite time now.
Because the compiler is deterministic and the cost of getting something better (based on the processor capability) is higher than just going with the compiled version, which has like 99.9% chance of being correct (compiler bugs are rare). It's not vibecoding. It's knowing your axioms is correct, when viewing the programming language as a proof system (which it is). You go from some low level semantics, upon which you build higher level semantics which forms your business rules.
So giving the LLM a fuzzy specs is hoping that the stars will align and your ancestors spirits awaken to hear your prayers to get a sensible output.
Compiler Explorer (godbolt.org) is quite popular. It's not uncommon for anyone working on performance sensitive code to give the compiler output a quick sanity check.
Hi Simon, thanks for your comment. I’m the author, just discovering the thread here on HN (and thanks everyone for the enthusiasm!).
I do think we need a new definition for vibe-coding, because the way the term is used today shouldn’t necessarily include “not even reading the code”.
I’m aware that Karpathy’s original post included that idea, but I think we now have two options:
- Let the term vibe-coding evolve to cover both those who read the code and those who don’t.
- Or define a new term — something that also reflects production-grade coding where you actually read the code. If that’s not vibe-coding, then what is it? (To me, it still feels different from traditional coding.)
I've been calling it AI-assisted development, but that's clearly not snappy enough.
I have a few problems with evolving "vibe coding" to mean "any use of LLMs to help write code:
1. Increasingly, that's just coding. In a year or so I'll be surprised if there are still a large portion of developers who don't have any LLM involvement in their work - that would be like developers today who refuse to use Google or find useful snippets on Stack Overflow.
2. "Vibe coding" already carries somewhat negative connotations. I don't want those negative vibes to be associated with perfectly responsible uses of LLMs to help write code.
3. We really need a term that means "using prompting to write unreviewed code" or "people who don't know how to code who are using LLMs to produce code". We have those terms today - "vibe coding" and "vibe coders"! It's useful to be able to say "I just vibe-coded this prototype" and mean "I got it working but didn't look at the code" - or "they vibe-coded it" as a warning that a product might not be reviewed and secure.
We professionals need to stop with paroles like "vibe coding is bad". If you don't have dev skills and experience, your code will be shit - no matter if vibe coded or manually done. If you can't guide another dev - here the a.i. - the result will be as good as the clueless leading the clueless.
Karpathy's definition was no guidance, just blindly copy and pasting error messages and code back and forth, hammering into place until it kinda worked.
Vibe coding can make it a lot harder to learn programming though, depending on how you use an AI. If you're a beginner and you can't read code very well, you're going to struggle a lot more when you have thousands of lines of the stuff written badly by an AI.
If you don't guide the LLM, vibe coding is Russian roulette, no matter how good you think you are. If you look at the code, it's not vibe coding any more by its original definition. So vibe coding is only “good” for code that gets thrown away real quick.
Personally, I find that if a model can vibe-code the functionality I'm working on then it's not very high-value functionality. Perhaps (a) it's boilerplate (fine), (b) I'm not creating enough/the right abstraction, or (c) the code could easily be written by a junior dev. If I'm working on truly new functionality, modeling complex states and assumptions, or producing something that generalizes to many settings, the model does poorly beyond being a souped up auto-complete.
That's not to say that these models don't provide value, especially when writing code that is straightforward but can't be easily generalized/abstracted (e.g., some test-case writing, lots of boilerplate idioms in Go, and basic CRUD).
In terms of labor I potentially see this increasing the value (and therefore cost) of actual experienced developers who can approach novel and challenging problems, because their productivity can be dramatically amplified through proper use of AI tooling. At the other end of spectrum, someone who just writes CRUD all day is going to be less and less valuable.
Boilerplate code is my signal to take a few moment and says do I really need all that code? Or should I write some generators/parsers instead? Even when I'm not able to, copy-pasting is often easier.
We have a simple rule: You commit it, you own it. If you vibe coded it that's okay. If it's garbage that's on you. Blaming the LLM doesn't count. So of course you have to read the code. You have to read it and understand it. Works well for us.
If you write code yourself your productivity is limited by how much code you can write. If you read/review code generated by AI, then it's limited by how much you can read/review. The latter is not that much bigger than the former. I believe at some point we'll have to let go.
I'm not clear on the point you're making, but I do know that reading/reviewing is often more time-consuming and harder than actually writing code - at least if you're doing it right.
Anyhow, I think we all just got too mesmerized with the LLM magic tricks and are slowly realizing that in real software writing we simply got a "slightly better stackoverflow". The claims of hyper-productivity are the same old ones of "I just copy and paste stuff other people wrote", i.e. people are just writing simple PoCs and really bad software - it's mostly bullshiters that couldn't and still can't do fizzbuzz.
The real stuff continues to be written same way as before - and this is gonna become more and more apparent as the LLM garbage sneaks in more and more software.
I'm still not sold on that. Stack overflow UI has lot of signals for a good response. The amount of answers, the upvotes on those answers, the comments,... With a quick scan, you can quickly see if you need to go back to the web search page (I've never used SO search) or do a slower read.
I am not struggling to believe it at all. Because I am an old guy with a CS degree but decades of web development experience. Apparently this is called being "a legacy developer".
This is the logical conclusion of the indiscipline of undereducated developers who have copied and pasted throughout their career.
This reality is then expressed as "but humans also copy and paste" as if this makes it OK to just hand that task over now to an AI that might do it better, where the solution is to train people to not copy and paste.
Everything about AI is the same story, over and over again: just pump it out. Consequences are what lawyers are for.
It's really interesting to me that within basically a generation we've gone from people sneering at developers with old fashioned, niche development skills and methodologies (fortran, cobol, Ada) to sneering at people with the old-fashioned mindset that knowing what your code is doing is a fundamental facet of the job.
+1. By now I've given up hope that software development will ever become a true engineering discipline, or even just somewhat close to it. Bungling it is so much cheaper and practically everyone seems to accept the current bad state of affairs. Only small subfields are exceptions to this.
Coding with AI agents is very similar to working with junior developers (or even other developers) in a team. Someone needs to give the project direction, keep the code organized, suggest refactorings, and many more things.
I guess it's really hard to work with AI agents, if you don't have real project experience in a more senior position.
> It’s always easier to straighten a sapling than a grown tree.
Ok, but in this case you can just throw away the tree and a new one will grow immediately for you to review anew. Rinse and repeat.
I'm not saying the author's proposed approach is never the right one, but there is a meaningfully different approach between the two suggested. You can look at the result of a fully autonomous agent, note the issues, tweak your prompt + inputs and then start over. You get the benefits of more closely-steered output without the drag of having to constantly monitor it synchronously. For some things, this approach is token-wasteful, but for small (yet critical / high-value) features, I have found it to work quite well. And an ancillary benefit is that your starting prompts and inputs improve over time.
But once you have carefully inspected 8 trees and thrown them away, you may need to start from sapling after-all.
And what about when you need a Forrest? Seed from trees grow new trees. A whole Forrest cannot be inspected and discarded over and over.
> but for small (yet critical / high-value) features
These are the features than need the human attention. These are the features that are the most fun for a human to make. These are the features that make the human improve the most. So it's the last ones i would leave to the AI.
Part of the definition of vibe coding is not looking at the code. If you read code you are not "vibing" anymore, you are just using AI tools to write code.
“using AI tools to write code” is too clunky of a phrase. Unless someone proposes a sticky two/three-syllable verb (that people actually want to use, inb4 some sarcastic person suggests “poop-coding” or something) then people are going to fall back on vibe-coding because it’s quick to say, its definition will become blurred, and we’ll have no one to blame but ourselves.
Readit News
Reminds me of Steve Yegge's short-lived CHOP - Chat Oriented Programming: https://sourcegraph.com/blog/chat-oriented-programming-in-ac...
I remain a Karpathy originalist: I still define vibe coding as where you don't care about the code being produced at all. The moment you start reviewing the code you're not vibe coding any more, by the definition I like.
My wife used the $20 claude.ai and Claude Code (the latter at my prompting) to vibe-code an educational game to help our five-year-old with phonics and basic math.
She noticed that she was constantly hitting token limits and that tweaking or adding new functionality was difficult. She realized that everything was in index.html, and she scrolled through it, and it was clear to her that there was a bunch of duplicated functionality.
So she embarked on a quest to refactor the application, move stuff from code to config, standardize where the code looks for assets, etc. She did all this successfully - she's not hitting token limits anymore and adding new features seems to go more smoothly - without ever knowing a lick of JS.
She's a UX consultant so she has lots of coding-adjacent skills, and talks to developers enough that she understands the code / content division well.
What would you call what she's doing (she still calls it vibe coding)?
I think orchestration may be a step that can't really be magicked away by advancements, beyond toy implementations. Because at the end of the day it is just adding specific details to the idea. Sure, you can YOLO an idea and the LLMs can get better at magically cleaning things up, but the deeper you go the larger the drift will be from the concept and the reality without continued guidance.
If LLMs could construct buildings you might describe what you want room by room and the underlying structure will need to be heavily revamped at each addition. Unless you start with "I am making a 20 floor building" you are going to waste a lot of time having the LLM re-architect.
I think the real new skill people are going to get scary good at is rapid architecting without any strong awareness of how things work underneath the hood. This is the new "web programming isn't real programming" moment where future developers might not ever look at (or bother learning about!) variables or functions.
So, clearly, almost nobody does that anymore. So according to Karpathy's definition, we have all been vibe coding for quite time now. (An aside - if AIs were any good, they would just skip human languages entirely and go straight to binary.)
So I think the "vibe" in vibe coding refers to inputting a fuzzy/uncertain/unclear/incomplete specification to a computer, where the computer will fill in details using an algorithm which in itself is incomprehensible for humans (so they can only "feel the vibes").
Personally, I don't find the fuzziness of the specification to be the problem; on some level it might be desirable, having a programming tool like that. But the unpredictability of the output is IMHO a real issue.
Because the compiler is deterministic and the cost of getting something better (based on the processor capability) is higher than just going with the compiled version, which has like 99.9% chance of being correct (compiler bugs are rare). It's not vibecoding. It's knowing your axioms is correct, when viewing the programming language as a proof system (which it is). You go from some low level semantics, upon which you build higher level semantics which forms your business rules.
So giving the LLM a fuzzy specs is hoping that the stars will align and your ancestors spirits awaken to hear your prayers to get a sensible output.
I do think we need a new definition for vibe-coding, because the way the term is used today shouldn’t necessarily include “not even reading the code”.
I’m aware that Karpathy’s original post included that idea, but I think we now have two options: - Let the term vibe-coding evolve to cover both those who read the code and those who don’t. - Or define a new term — something that also reflects production-grade coding where you actually read the code. If that’s not vibe-coding, then what is it? (To me, it still feels different from traditional coding.)
I have a few problems with evolving "vibe coding" to mean "any use of LLMs to help write code:
1. Increasingly, that's just coding. In a year or so I'll be surprised if there are still a large portion of developers who don't have any LLM involvement in their work - that would be like developers today who refuse to use Google or find useful snippets on Stack Overflow.
2. "Vibe coding" already carries somewhat negative connotations. I don't want those negative vibes to be associated with perfectly responsible uses of LLMs to help write code.
3. We really need a term that means "using prompting to write unreviewed code" or "people who don't know how to code who are using LLMs to produce code". We have those terms today - "vibe coding" and "vibe coders"! It's useful to be able to say "I just vibe-coded this prototype" and mean "I got it working but didn't look at the code" - or "they vibe-coded it" as a warning that a product might not be reviewed and secure.
Blind-coding.
Dead Comment
Deleted Comment
That's not to say that these models don't provide value, especially when writing code that is straightforward but can't be easily generalized/abstracted (e.g., some test-case writing, lots of boilerplate idioms in Go, and basic CRUD).
In terms of labor I potentially see this increasing the value (and therefore cost) of actual experienced developers who can approach novel and challenging problems, because their productivity can be dramatically amplified through proper use of AI tooling. At the other end of spectrum, someone who just writes CRUD all day is going to be less and less valuable.
Passive code reviews ("read by at least two humans") are fraught with error. IMHO, a better mantra is:
So you measure “productivity” in lines of code? Say no more.
I'm still not sold on that. Stack overflow UI has lot of signals for a good response. The amount of answers, the upvotes on those answers, the comments,... With a quick scan, you can quickly see if you need to go back to the web search page (I've never used SO search) or do a slower read.
This is the logical conclusion of the indiscipline of undereducated developers who have copied and pasted throughout their career.
This reality is then expressed as "but humans also copy and paste" as if this makes it OK to just hand that task over now to an AI that might do it better, where the solution is to train people to not copy and paste.
Everything about AI is the same story, over and over again: just pump it out. Consequences are what lawyers are for.
It's really interesting to me that within basically a generation we've gone from people sneering at developers with old fashioned, niche development skills and methodologies (fortran, cobol, Ada) to sneering at people with the old-fashioned mindset that knowing what your code is doing is a fundamental facet of the job.
I guess it's really hard to work with AI agents, if you don't have real project experience in a more senior position.
(To be fair my kind of testing is a lot different than unit tests, and the tests I'm cancelling are mulit-page forms that require three signatures.)
Ok, but in this case you can just throw away the tree and a new one will grow immediately for you to review anew. Rinse and repeat.
I'm not saying the author's proposed approach is never the right one, but there is a meaningfully different approach between the two suggested. You can look at the result of a fully autonomous agent, note the issues, tweak your prompt + inputs and then start over. You get the benefits of more closely-steered output without the drag of having to constantly monitor it synchronously. For some things, this approach is token-wasteful, but for small (yet critical / high-value) features, I have found it to work quite well. And an ancillary benefit is that your starting prompts and inputs improve over time.
And what about when you need a Forrest? Seed from trees grow new trees. A whole Forrest cannot be inspected and discarded over and over.
> but for small (yet critical / high-value) features
These are the features than need the human attention. These are the features that are the most fun for a human to make. These are the features that make the human improve the most. So it's the last ones i would leave to the AI.