The problem with this little post is, that vibe coding just is not a "better" way to code. It strips development of something from all the fun developing, from circling around an idea, from figuring out something with your own brain, from trying and testing new stuff, from actually working as a developer...
If you genuinely "vibe-code 24/7", you don't develop software, you are translating business logic rules to a set of long explained commands and put it in a black box and hope it works...
Integrating AI in a meaningful way while keeping the same consistency and maintainability of a software project is hard, just throwing EVERYTHING at an LLM has not really worked out in the last few months to a year yet...
Or you are like me and you love having ideas, you love solving business and technical problems but you don't like the "execution" part.
Because from my experiment at "vibe coding", LLMs for code are good at following the rules, not at being intelligent. They are especially bad at keeping the "big picture" in their context.
In fact you can talk to your IA at the level of abstraction you want :
1 - You can ask it to create an entire app and, for sure, that'll be a black box full of unknown bugs.
2 - Or you can just give it precise instructions : "create the model for x entity with exactly those characteristics". "Now let's create the controller for the API but pay attention to this or that".
If you are good at describing things, LLMs are excellent at doing what you are already good at. They'll write exactly the code you would have wrote, they'll take care of the boilerplate, they'll self correct if needed except they'll do it in seconds while it would have took you hours between just typing the whole thing, debugging your own mistakes, going back and forth files, refactoring your implementation ...
Sure it takes more time than just asking "make me a snake game in pygame" but it also takes so much less time than writing it yourself.
Also, but that's only my personal experience, working with LLMs, even with a lot of iterations helps me a lot with staying in flow.
That's literally what has been happening forever though. Think how complex the abstractions are from something like SQL to the actual CPU instructions that are being executed on a modern OS.
The thing I'm most excited about with 'vibe coding' isn't really existing software developers making things. It's people with deep domain knowledge who can't program can now build stuff. It's more of an excel replacement imo as it gets into the mainstream.
I am sure that most LLM generated software projects are more easily understood at a code level than the average excel 'megasheet' created by this kind of person, and certainly will be less brittle to a certain degree.
I think the problem with vibe coding though is it’s not bi-directional, like if you have deep domain knowledge, unless you know how to code, how do you know that the code it just created actually does what you want it to, especially as it gets more complex and your new code changes old code. You could ask, but the devil is often in the details, especially if your domain is highly technical.
> how do you know that the code it just created actually does what you want it to
I believe that problem can be solved, and will be with the correct new tools.
I think a new type of "low-code" programming language will evolve tailored for domain experts that don't know coding, but understand how to guide an LLM.
The development environment should be a crossover between a project-management tool (Jira or Azure devops style) with literate programming: something that allows organising all the separate parts that compose the program in a way understandable by the human and the AI bot.
Online notebooks are a good first step in that direction, in special the "reactive" kind where the runtime logic does not depend on the order you change things in the page.
Except vibe coding doesn’t work for non-programmers except in the hype propaganda. In reality these tools are only powerful in the hands of real programmers who are able to understand what is being produced and can adapt and maintain it.
To me, it's always wild to see people trying to prove this is "the future" and "no one will ever code again". And then they try to prove it by building a react todo app, something that has been done millions of times and is really just an advanced hello world project...
I've had great success using AI for some tough things, but not on an entire foreign codebase that requires domain knowledge, no matter how constrained my prompts are. As soon as your use-case goes above the average "building a small tool and make it a $4.99 saas startup", AI really only helps you with the exact code to transfer your already pre-planned pseudo-code/behavior.
And even then, you need the knowledge to understand that what the AI merged out of the millions of StackOverflow answers is actually outdated or a hallucinated API function that never existed.
I did this analogy in the past and I was way downvoted. Just for clarification, I use vibe-coding a lot in side projects where I don't know if I am going to release it at all, or when I know that a mistake in the code won't crash a business.
However, when I do vibe-coding, I feel like a PM asking a remote team to do code and I get back the response asap. It could be good or it could be bad, but if I don't check it, I am just a PM trusting 100% what my engineer (team) did. How did this work in reality before IA? Well, the engineers had to have some kind of responsability and testing, and assuring that what they did was OK. Now that part is completely "disabled", and the PM Is responsable for the tech aspect as well, without the knowledge (and I am avoiding all the deploy / infra perspective).
I may also just misunderstand the term itself. From what I've seen, "vibe coding" is used as a term for someone who does not want to go into the details, who does not want to check or adapt the code, who just wants to explain their idea to an LLM and expect a fully built feature, without doing any of the development themselves.
I myself use AI all the time, for smaller things, for more math-heavy things, for decisions I already thought about but want to check with best-practices (after all, LLMs are trained with the "hive mind" thoughts of programming). I use it as a companion, a tool akin to JetBrains refactor tools, something I can drop on a specific function to enhance my own work.
Here's the thing. What you're doing when you're vibe coding is iteratively creating specifications for software, which the LLM is capable of converting to runnable code. Insufficient specs will lead to code that doesn't do the right thing.
Chat is fundamentally the wrong interface for this. My instructions to the LLM in a chat session are effectively the software specifications, but chat encourages to treat them as ephemeral.
It's analogous to writing code in a high-level language, then deleting the code after it's compiled and keeping only the low-level bytecode.
In the case of vibe-coding, my specifications to the LLM _are_ the code, and the LLM-emitted code is a _artifact_ that can in principle be discarded and re-generated, assuming my specs are precise enough to ensure consistent outputs (the nondeterminism of LLMs is definitely a issue here.)
So I want tools that let me persist my specs, help me iterate on them, check them into version control, and help me test how the LLM interprets them. Not a chat.
Except most LLMs are not deterministic, the same prompt will, in general, produce different outputs because the sentence completion ist statistical and randomly selected
What matters is if the current output after each request complies with the given specifications, and if it's possible to solve the bugs until the code converges into stability.
This was written as VC fluff. It is impossible to agree with an argument of having control over code when theres a middleman which interprets natural language.
The human won't understand how the codebase works when the codebase is developed by AI. Coupled to the fact AI misunderstands and gets things wrong, any company worth an audit needs more assurances
Just like with no-code, vibe-coding has the same "interface problem". With no-code you were locked down to using the provided editor and had to constantly flight it to get what you wanted. Now it's no different except you are not typing natural language into a prompt and fighting it to get the correct output.
Vibe coding just like no-code will work to a degree, as you can easily build simple apps with either solution. It's just when you start building something bigger that both systems completely fall apart. While I welcome both technologies and think that it will help non-technical folks write code and build stuff. The world is still powered by "large" software and that's the stuff that you can't just vibe code your way through.
Are we not seeing parallels here? No code was touted as a way to eliminate coding altogether. Loved by the business, didn't work in practice. Vibe coding; a way to eliminate (maybe reduce). I see the pitch, but the jury is out on how it will work in practice.
> It turns out people didn’t want less code — they wanted a better way to write code.
Wanting "a better way to write code" is one thing. Finding a way to usefully fit LLMs into your workflow is another thing. "Vibe coding" is yet another thing, distinct from the first two. Vibe coding is to programming as throwing a water balloon full of paint at a canvas is to painting. It works just as long as you don't actually care about the result.
I originally read this as "No, code is dead..." and thought here we go. I agree with the sentiment in this, and seems to line up with my experience with friends and colleagues of various persuasions. Certainly for anything React-like and front end heavy, people can scratch itches like never before. I still think it's heavily towards the "throwaway" and relatively small side of this, beyond that I think if you're not already somewhat familiar, you'll hit a brick wall.
Agreed, the article's perspective is much narrower and I think it makes total sense.
Previous no-code tools could work but required total buy-in. On the other hand you can have Claude generate a small throwaway frontend that relies on Web technologies you'd be using anyway.
My mental model for this is "Excel++". It has similar strengths (very powerful, users don't need developers to write every last line) and similar weaknesses (easy to make a mess or go down blind alleys if you don't know what you're doing).
This post seems to suggest that no-code tools like Webflow and Retool are dead or dying. Nothing could be further from the truth - no-code is a booming business, moreso than many developers (who, by their nature, do not like or need such platforms) may realize.
Hearing professional developers talk about how no-code must be useless and/or dead, is kind of like hearing a professional swimmer say that floaties are dead.
> Natural language is proving to be a more powerful interface than drag-and-drop WYSIWYG editors.
Completely disagree. What “vibe-coding” weirdos are experiencing is that 99% of the time they need code for a solved problem. However this magical vibe coding falls apart as soon as you need nuance.
There is a difference between “generate me a nextjs app with typescript and unit tests” and “create-next-app” with typescript and unit tests. The first is guessing at what you need the latter is pushing out what you need exactly according to a template. Vibe coding falls apart when you need to spend time tweaking your typescript config because the LLM just used the most popular collection of code strings it found that leads to a working app instead of create-next-app.
A wysiwyg editor provides better interface because you know what you are getting when you click the button. You aren’t asking a computer to infer your intent. Vibe coding requires writing natural language that then needs to be parsed into intent. There is your error gap right there, going from “I need this” and “hoping” a computer grasps your intent correctly.
There are also people actively poisoning the well for LLMs with LLMs so your prompt will always be at risk to be misinterpreted. That is not “production grade”.
Vibe coding looks amazing at first, especially if you don't know how to code.
You click a few things, move stuff around, and it feels like you're building something real. But then it gets messy. You try to change one thing, and ten other things break. It becomes frustrating fast.
But if you already know how to code, it's actually great. You can tell what went wrong, fix it, and keep going. It’s fun when you can fall back on your skills. Not so fun when you can’t.
"Production-grade" is a stretch. These AI coding tools can generate impressive prototypes, but there's still a massive gap between what they produce and code that's actually ready for production.
I don't understand the disconnect between engineers who work with these tools daily and the investor/exec/founder/influencer-types who constantly hype them. My LinkedIn feed has become a comedy.
I feel like any senior SWE who's tried to maintain an AI-generated codebase, coach a junior who's found themselves reliant on Cursor; or found themselves in an undo, yell, repeat cycle in Cline, knows they still require significant expertise to build production-safe code.
Long live vibe coding? Only one of the four words in that sentence has a specific verifiable meaning. That one word, coding, represents an activity that is worth keeping.
If you genuinely "vibe-code 24/7", you don't develop software, you are translating business logic rules to a set of long explained commands and put it in a black box and hope it works...
Integrating AI in a meaningful way while keeping the same consistency and maintainability of a software project is hard, just throwing EVERYTHING at an LLM has not really worked out in the last few months to a year yet...