Vibe Coding Is NOT My Future

In case you haven’t heard about it - there’s a new way of coding: Vibe Coding.

Vibe Coding Definition

It’s a term originally coined by Andrej Karpathy and introduced as a LLM-powered way of coding “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists”.

The idea is that you let an LLM (like Claude Sonnet) generate code by just asking for things like “decrease the padding on the sidebar by half”. Instead of writing code yourself, or at least analyzing the generated code in-depth, you “just copy paste” error messages “with no comment” to fix any potential problems you might run into.

You therefore generate code, and, ultimately, entire applications by just asking for features & bug fixes.

In case you wonder how this way of coding went for me, you can watch 2 hours of pain and agony (or the shortened version ) of me trying to build a simple mobile app with React Native & Expo by using vibe coding and not writing any code myself.

Of course, I’m fully aware that there are people who seemingly build great things the vibe coding way. Most prominently, Pieter Levels built a web-based flight simulator game (though it’s probably worth mentioning that the game looks the way it looks, included a XSS vulnerability and likely gained its popularity due to Pieter’s status & reputation).

As shown in the videos linked above, my experience with Sonnet 3.7 has been nothing like that shared by Pieter and some AI influencers.

Now, I got some ideas on how to become better at vibe coding. But despite those ideas, I have even stronger reasons to not adopt it as my future way of coding.

How To Vibe Code

Here are some thoughts I have regarding why some people seem to do better at vibe coding:

• Instead of starting with an overall plan (for the app / game), people with better results are likely just asking for very small building blocks & features. This might better suit the way LLMs work & generate code.
• Related to the previous point: If you got no fixed vision for the end result, you might simply discard features that just won’t work the way you want them to work. Being able to move on and ignore problems that can’t be solved of course helps.
• If you try long enough, and you maybe even try random stuff (Andrej Karpathy: “Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away”, source ), eventually errors may be fixed, or the code may have changed enough so that things start working (though, as a side-effect, other parts of the app probably also changed in the meantime).
• Since LLMs don’t generate output in a deterministic or predictable way, luck is definitely also a crucial factor.
• Knowing how to write good prompts with just the right amount of information and context definitely also matters - you can watch me failing to judge my prompting skills.

That’s just a list of reasons that came to my mind. You could probably add more. But I’ve seen enough to pass on the vibe coding approach.

Why Vibe Coding Is Not The Future (For Me)

So, why’s vibe coding not the future?

I understand that it sounds great, especially for people who don’t know how to write code or who’re just not good at it (and have no motivation to improve their skills).

I’m also fully aware that some people will take my opinion here as gatekeeping. Since I could probably only change that impression by changing my opinion, I’m afraid that’s just something I have to accept.

But at least regarding the first point (vibe coding for people with no / poor skills), I do agree: Vibe coding can definitely help you build things (quicker) than you would otherwise be able to. You can try building all kinds of applications or games, and if you just keep on trying and prompting long enough, you may end up with a working application or game.

No-code, low-code and AI-code platforms like Wix, v0, Lovable etc. can help with that.

Of course, that’s partially been true before AI, too. You could build websites without any coding skills in the past, too.

But I see three main problems with vibe coding:

1. If you do know how to code, writing that code, instead of trying to get a LLM to produce the right code, is faster
2. Treating and shipping code as a “black box” with unknown bugs or security issues is problematic
3. When working in teams and based on project plans, vibe coding sounds like a bad idea

Let’s explore these three problems in greater detail.

1. Knowing How To Code Is More Productive

What’s faster?

Telling an AI to generate a short email where you want to send three specific bullet points to a colleague, revising the draft and copying & pasting it, or just writing that email on your own?

Of course, writing the email yourself is.

At the same time AI can be very helpful when it comes to refining more complex emails, summarizing text, coming up with synonyms, providing feedback etc.

And it’s the same for coding.

If I know which code I generally need to write, I’m typically faster doing so than prompting an AI, hoping that it will produce good code. At the same time, I’ll happily use AI assistants to generate boilerplate code, help me with smart auto-completions (though those can also be problematic ), analyze my code, or debug errors.

So, probably unsurprisingly, I prefer getting the best of both worlds (knowledge + AI assistance) over replacing my skills with AI.

Now, of course, you will often face challenges for which you don’t know the solution yet. That’s a big part of being a developer. It happens to me all the time.

In such situations, AI will very likely be able to generate code faster than I would be able to write it.

BUT: The alternative is to find a solution yourself and therefore evolve your skills. That’s how learning works! And guess what, the next time you’ll face a similar problem you’ll likely going to beat the AI.

We really shouldn’t use AI as an excuse to become dumber. At least not as long as knowledge + AI > just AI.

2. Treating Code As A Black Box

Being potentially more productive is one thing. Not understanding or even checking (!) the generated code is another.

And, just to be clear: Human developers also introduce bugs and security issues.

But besides the fact that, unlike some AI, you’re accountable for your code, there also is a big difference between understanding what your code generally does and not having a clue at all.

If you understand your code, you can actively evaluate it for potential problems or security holes. And if problems do arise, you can very likely quickly narrow down the issue, instead of iterating with AI, hoping it gets things right.

It’s also not unlikely that you know about certain common pitfalls as well as best practices that you’ll incorporate into your code. AI-generated code on the other hand tends to produce the code it’s seen a lot in its training data. That is, unfortunately, not necessarily always the most stable, maintainable or secure code.

Personally, I would not feel confident pushing AI-generated, unchecked code to production.

3. Vibe Coding Doesn’t Vibe with Teams & Plans

I’m going to keep this one short, simply because I don’t really work in teams at the moment. Hence I can only share some thoughts, not personal experiences.

But I can only imagine how chaotic things may become if multiple developers “vibe code” their way on a shared project.

Combined with the fact that vibe coding doesn’t really seem to vibe (sorry!) with clear plans, milestones and distributed work, I’d be surprised to see a lot of teams using this approach any time soon.

Also: Human Language Is Horrible For Transporting Relevant Information

Here’s one last point that matters to me.

Related to that whole vibe coding thing, I know that there are also people who are convinced that in some near future, we’ll just use natural language as code.

So something like this:

get some input value and multiply it, if possible, with 2

could replace

function double(num) {
  if (typeof num !== 'number') {
    throw new Error('Invalid value, expecting value of type number.')
  }
  return num * 2;
}

Here are some problems I see with that future:

• what if the underlying AI decides to not throw an error but silently fail for invalid values
• what if the underlying AI starts hallucinating and generates an invalid result (e.g., due to some less commonly used input value like -189.12141219)
• what if the underlying AI generates some result but decides to output not just the result but also some additional explanation text that may then cause problems in some follow-up steps in your program?

You could probably come up with more issues, but they all pretty much boil down to one root reason: LLMs don’t generate text in a predictable or deterministic way. The same input (text) will lead to different output (text) all the time.

Natural language is great for many things. But when it comes to conveying information and describing intent in a concise and unambiguous way, there are better alternatives. Like, for example, programming languages.

I believe, if we were living in a world where our human language would currently be the default way for creating computer programs, we would eventually invent programming languages - simply to be able to write deterministic code and ensure predictable behaviors.