Vibe coding has become extremely popular nowadays. Its popularity has risen so quickly that even non-tech people are aware of it. Reactions to it are mixed. Some people love it with passion. Others are skeptical and say, “Meh, whatever…” Some people have deep concerns about its implications. But what exactly is vibe coding?
The Origin of Vibe Coding
I think before we dive into the details, we should first take a look at what the man who coined the term says.
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. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
— @karpathy on X
In spite of different views on the terms “vibe coding”, I think we can come to the agreement that vibe coding involves some level of autonomy. In this new paradigm, the developer (whether tech-savvy or not), delegates the some or all coding responsibilities to the AI coding agents. I think this where the disagreements come, that is, how much autonomy should be given to the AI coding agents and the process can still be considered as vibe coding.
Please note that this is not a criticism of Andrej Karpathy’s original post. In this blog post, I will simply use his original tweet as a reference to explain my personal take.
My Personal Take on Vibe Coding
Forget about code
where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
— @karpathy on X
I am actually not against this. Ideally, if you want to vibe code, you should not be needing to know the internal details. This approach might work for small projects, scripts, or non-critical applications. However, for larger projects, the current state of AI coding agents is not quite there for the job. Regardless which coding agent, whether Cursor, Windsurf, Cline, GitHub Copilot, or event Claude Code, you will want to review the generated code to ensure it’s secure and maintainable. You probably have heard the stories that so and so vibe coded this aweseome project in a week. It’s now in production and has a sizeable user base. But suddenly there’s a security breach and the project is compromised. The developer has no idea how to fix it.
As the AI coding agents are getting smarter, the quality of the generated code will continue to improve. Issues related to security and maintainability will be less of a concern, but I don’t think they will competely go away. Compared to natural languages, programming languages are deterministic and precise. I think we will still need a way to audit what the AI coding agents create. There will be a group of people who specialize in reviewing code and ensure the applications doing what they are intended to do.
My take: You can vibe code, and you also can (and should) review the generated code.
Not reviewing the changes
I “Accept All” always, I don’t read the diffs anymore.
— @karpathy on X
Continue from the previous discussion, may I suggest a middle ground? What about “Accept All” during the coding session, that is, when you vibe code, but review the diffs in the end?
This encourages good habits as you will want to vibe code in small increments. It’s easier to review small changes than large ones.
My take: “Auto approve” as needed to reduce fatigue, but review the diffs in the end often. Also, manually approve risky operations such rm -rf or curl.
Vibe coding
I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it.
— @karpathy on X
This is what we all are dreaming of, isn’t it? To me, this is what vibe coding is all about. You create a new feature or make a change to the application via a natural language. You operate at a higher level of abstraction. You don’t deal with code directly—instead you follow the vibe and tell the coding agent what you want. You let the coding agent to handle the heavy lifting so that you can focus on the big picture. It sounds like sci-fi, but it’s actually totoally doable today. I am still in awe.
That’s to me is vibe coding.
My take: Utilize vibe coding much as possible. At the same time, provide enough details (i.e. context) for the coding agent. There’s nothing wrong making the coding agent’s task easier. It’s a win-win situation. Just like working with a coworker, you will want to provide clear instructions so that your coworker can do the work effectively.
The original post was talking about a throwaway project
It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
— @karpathy on X
Just like I mentioned earlier, the 100% “pure” vibe coding approach is not for production applications. There’s no problem with that for a quick script or a throwaway project.
However, for critical production applications, you will still want to be disciplined. The engineering principles and best practices are here to to stay. They will help us create quality and maintainable code.
My take: When possible, apply best practices even when vibe coding.
Tip: look up DRY (Don’t Repeat Yourself), KISS (Keep It Simple, Stupid), and SOLID principles, 12-Factor App, TDD (Test Driven Development) etc. These these principles to your editor’s custom instructions.
But would you still call this vibe coding?
Why not? There’s a saying: “Let the process serve you, not the other way around.” When I use natural language to develop features, I want to get the best out of it (thus introducing best practices). Also, I don’t be constrained by a ridig process. I’d like to have the freedom to improvise and adapt workflows that fit my needs.
My take: You can and should improvise vibe coding to fit your needs.
Conclusion
Vibe coding is a new paradigm that allows developers (tech-savvy or not) to operate at a higher level of abstraction. It enables you to focus on the big picture and let AI coding agents handle the heavy lifting. However, it’s important to recognize that there’s no single textbook definition of vibe coding. You can modify and adapt the process to fit your needs while still embracing the core values of vibe coding.
My mini vibe coding manifesto:
- Don’t forget the code:
You can vibe code, but you should still review the code. - Grant autonomy with caution:
Use “auto approve” as needed to reduce fatigue,
but manually approve risky operations. - Flexible adoption:
Leverage vibe coding as much as possible,
but improvise to suit your own needs. - Ignore external pressure:
Choose whatever workflow that works best for you. You don’t
need to conform to anyone else’s “vibe coding” standards.
Happy vibe coding!