Vibe Coding. Will Programmers Die Out?

Spoiler: of course not.

Let’s think this through. Who are programmers? The clearest answer is: people who can think algorithmically. Whether they write code in Java, C++, Python, or PHP is not the main point. What matters is writing deliberately, embedding an algorithmic foundation into the code so that it solves the task efficiently, reliably, and predictably—while also remaining understandable, readable, and maintainable. It also matters to come up with algorithms not by brute force, but by understanding the domain, studying input and output signals, and analyzing existing business and automation processes.

A great many "programmers" have been bred trained, but they are "programmers," not programmers. Demand created supply, but demand was driven more by quantity than by quality. We all remember how banks vacuumed up the market and hired engineers by the thousands. Now the reverse process has begun, quite naturally. Demand for specialists who are sitting at the peak of stupidity on the Dunning–Kruger curve has disappeared, and AI in the hands of a new caste—prompt engineers—can handle their tasks just fine. But prompt engineers are not real engineers; they are imaginative writers and curious pioneers who were the first to figure out how to present the output of generative models as their own intellectual labor. Clever charlatans.

In the 2000s, programming languages were developing rapidly: new ones appeared, existing ones evolved, and convenient frameworks, patterns, libraries, classes, methods, and so on emerged. Programming became very convenient, comfortable, and fast. In the past, you had to write low-level helpers yourself and endlessly optimize and refine them. At the university, we were taught algorithms from day one. We solved sorting, compression, encryption and decryption, and packaging problems at a low level. Solving that class of problems taught us to think algorithmically and to create under resource constraints.

What did frameworks bring? They simplified software creation. Today, to sort an array, it is enough to write something like "my_array.sort(ascending)," and the program will handle it automatically. But the modern "programmer" will not know how the sorting was actually performed, will not understand its characteristics, and will not tackle the harder problem of accelerating sorting on large arrays—because real programmers already solved that for them. Yes, I may sound like a grumpy old man, but let me give an example to make the point clearer. Imagine you are preparing dinner for a date. There are several paths: order delivery, buy frozen convenience food and microwave it, or buy fresh ingredients and cook dinner yourself. Here is where I am going with this: the first option may be great if you order from an expensive restaurant that will prepare an excellent meal from quality ingredients and deliver it. That is easy, but slow and expensive. Or you can order fast food—in that case it is quick and inexpensive, but not as tasty or healthy as in the first scenario. The second option is to buy frozen ready-made food and heat it up. You know what to expect there. The third option is difficult and perhaps time-consuming, but if you know how to cook well (as I do, for example), then it is a completely different level. Returning to programming: the first option is custom development, the second is vibe coding, and the third is clean, beautiful code that you spent years learning to write.

Now every second "programmer," after getting access to chat tools, has started sincerely believing in their own power and building ambitious projects from a simple prompt, without thinking too much about wording or grammar. The model’s answer amazes them: the code looks beautiful, runs, works fast, and often the interface is excellent. It creates a sense of simplicity and accessibility. But unfortunately, a vibe coder is not capable of performing a proper code review, nor even of simply scanning the code for vulnerabilities and logic errors. They will click around the interface and feel satisfied, but this creation will not become a program, will not become a product, and the vibe coder will not become a programmer unless they begin to understand the code themselves.

When smart calculators appeared, you did not start calling their users mathematicians, just as you do not call someone a chef because they ordered a delicious dinner from a Michelin-star delivery service. The same applies to vibe coders: they are not programmers, just like generative models are not programmers. Generative models start hallucinating by the third iteration of fixing a simple bug, forgetting what they did two steps earlier. That is a major problem with vibe-coded projects: if you do not establish the right program architecture and code structure, the model starts glitching and forgetting its prior work.

And what role will real software engineers play in the world of vibe coding? Programmers will simply roll up their sleeves and carefully breathe meaning and life into the output of vibe coders for appropriate compensation, collecting and fixing the errors and inconsistencies in automatically generated code that is otherwise difficult to evolve. Remember the 80/20 rule: 80 percent of the code is written in 20 percent of the time, while the remaining 20 percent takes the other 80 percent of the effort—and AI still cannot write that part. Learn to program.

P.S. By the way, I have nothing against vibe coding for prototyping, solving point problems, and testing hypotheses. I use it regularly myself and I always read and verify the code. I make targeted edits. And yes, I can teach you how to vibe code properly in my academy, which I vibe-coded myself last summer :)