In the past, we have seen many technological transitions in programming languages. Today we see a new transition, which is called Vibe Coding. Vibe Coding is not in its final state, but we can already see the direction. The idea of Vibe coding is: don't look to the source code. Tell an AI what to do and then the AI modifies the source code. We currently don't know if the best way is for the AI to modify the code or to generate the code from the requirements and prompts again and again (what I call one-shotting), but the idea is to not look at source code.
Many people today say Vibe Coding does not work. It creates situations where the code does not work and you can't get out from it. That might be true because the tools are not yet there. But when we look to the past, we can see some patterns where this has happened before.
The first transition was from machine code to C that I experienced myself, at a time many people were writing mostly machine code. And then for efficiency, people developed compilers, and compilers, specially C compilers and Pascal compilers, entered into the mainstream. And all those machine code programmers said "I don't trust the compiler, I know what code it generates. I don't know what's running there, so I will not use C compiler because I don't know what code is generated, how the machine code looks like. It probably isn’t the best code."
Later we had the transition from C to Java. And the biggest jump here was introduction of garbage collection. Developers need to make a leap. With C you had to manually manage memory with malloc. And you had very precise control over how memory was allocated and freed in your application. With Java, garbage collection entered the mainstream. And garbage collection does all the allocating and freeing of memory for you. You don't know when memory is allocated. You don't know when memory is freed. And all those C programmers said "I don't trust garbage collection. I don't know what memory allocation it does, so it can't work. It probably doesn’t create the best memory allocation." And they stayed away from Java and other garbage collection languages.
And in both instances we see that the best developers, the oldest developers, the developers with the longest experience, stayed with the technology and rejected the newcomer. While new developers did not get into the old thing, but new developers got into the new thing, they got into writing C instead of machine code. They got into Java with its garbage collection instead of manually managing memory.
And today we have Vibe Coding so developers telling an AI with a prompt what code to write or what program to write without looking to the code that is generated. Like we don’t know what machine code a C-compiler generates, or what byte code the Java compiler creates. We see the best developers and the most experienced developers in Javascript, or in Python say "this is not working. I don't see the source code. I don't know what the AI is doing. This might break."
And the new developers jump on it and go with Vibe Coding and AI prompting full in.
Before in the transitions from machine code to C and from C to Java, the new developers were right. And the developers who stayed with machine code and stayed with writing C, they were delegated to a niche. They have still jobs, but only a tiny fraction of developers does this today.
People worry about Vibe coding:
Loss of Engineering Precision: Vibe coding undermines the engineering discipline in software. By hiding the actual code, developers don't understand system internals, creating a dangerous "black box". When things break, troubleshooting becomes nearly impossible without knowing what the AI actually made. This might work for simple apps, but real systems need precision and understanding that Vibe coding avoids.
Dependency and Security Risks: Relying on AI for code makes us dependent on big tech companies. Plus, AI code might have security problems that are hard to find because developers aren't looking at the code directly. Without human review, how do we know the AI hasn't created weaknesses that hackers could use? You can't "trust but verify" when verification is deliberately skipped.
Skills Degradation: Vibe coding creates developers who can't actually program. By just describing what you want to an AI, we risk having developers who don't understand algorithms or how systems really work. This makes our digital infrastructure more fragile. Innovation will suffer because people won't be able to think about problems at fundamental level.
But these worries sound just like what people said about previous programming changes. Assembly programmers complained about C compilers taking away control of machine instructions. But compilers ended up making better code than humans. Vibe coding doesn't get rid of engineering - it just moves it up a level where developers can focus to architecture and requirements instead of implementation details.
The security argument assumes human code is more secure, which isn't true. Programmers make security mistakes all the time. AI code generation is starting to include security checks that might actually make code more secure than what humans write. And with open-source AI models becoming available, we won't be stuck with just few big companies.
As for skills, technology always changes what skills matter. When calculators came out, people worried about basic math skills. Some skills did decline, but we solved more complex problems instead. Vibe coding doesn't eliminate thinking - it frees developers from boring implementation work. Just like today's developers don't need to understand memory management, future developers will focus on design and problem-solving rather than syntax - and they'll make better software because of it.
Was Java perfect when it arrived? No, we had lots of problems with garbage collectors. We had minute long pauses with GCs on very high traffic days. I paid a consultant lots of money to fix our garbage collection problems. After some years that just went away and GCs today in Go and Java and other languages just work.
Would I use Vibe Coding in it's current state for mission critical systems? No. For my main application I build the company on? No. For a prototype? Yes. For MVP? Yes. For a marketing application? Yes.
Close your eyes and make the leap.
"Many people today say Vibe Coding does not work. It creates situations where the code does not work and you can't get out from it"
It's true to say that Vibe coding doesn't work for most complex existing solutions today.
But that's a temporary aspect; things will transition into a phase where this will be possible.
Today, Flow Coding with AI, which I do in production with Claude Code, works well. I can take this hybrid approach because I am still the engineer and partly the coder. As a humans, we run at the pace of man, not at the pace of AI, which is the main difference between vibing and flow coding.
The reason is that our codebase, a complex, multi-tenant B2B solution, was never meant to be built in a "black box" while vibing. But it's compatible with AI in the sense of Flow Coding.
Newly started projects can work with vibing today, at least to some degree, since it's a relatively new technology. At its current enhancement rate, it won't be long before we can create AI-driven solutions on a more complex scale. The biggest question then will be, "Who is we then"?
We developers, We Engineers, or We business people?
BUT:
Those solutions will look different. Those codebases aren't meant to be worked on together with humans. A human will be the engineer outside of this black box.
When?
The companies will shift; Some are doing that today, a few will start soon, and most others will wait years before doing anything (traditional). I don't think this transition will be a fast one. For this, I have spent too much time in the market as an entrepreneur and engineer. I know things are slow. See all the old PHP/ASP.NET Legacy System people still work on.