Why vibe coding will be the new industry default

TL;DR: Vibe coding is just a new abstraction layer, engineers will move to higher concepts.

Our daily interactions with computers run through many abstraction layers. When I use a web browser, I am invoking many layers, and code which has been written by thousands, potentially hundreds of thousands of engineers. The code is executed on many different computers and networking devices, with silicon which has been developed by huge companies with hundreds of thousands of total employees, including highly qualified engineers.

All this functionality is packaged for me, and many other people like me, in an easy to use, abstracted fashion. I don’t deal with bits, networking protocols, or cryptographic algorithms: I use tabs, URLs, bookmarks, my mouse, and – nowadays – AI.

In the same way, most software engineers today do not code at very low levels. No one, since the 1970s, has been entering code in zeros and ones using toggles.

Yes, Bill Gates and Paul Allen used to toggle their Microsoft Basic onto the Altair 8800 computer in this way:

Von Dr. Bernd Gross – Eigenes Werk, CC BY-SA 4.0, Link

Assembler arrived as early as 1947 (Kathleen Booth and her contract notation for the ARC2 computer). Even though some people, like John von Neumann, believed that it was a waste to use an expensive machine on clerical work – translating assembler instructions into machine code – the idea stuck, and spread in the mid-1950s.

Libraries (1949), und user groups also arrived earlier than most people expect – IBM had a user group called SHARE since 1955!

Unix’ libc became available in the 1970s, while online package repositories – the refined form of the idea – became available much later, with npm arriving as late as 2010.

Surprisingly, the first compiled language – Autocode (Glennie, Manchester), arrived in 1952.

The first widely adopted high level language was FORTRAN in 1954-1957 (Backus, IBM), LISP (1958) and COBOL (1959) followed soon after. C, which is a language still widely used for low-level drivers, and system utilities, arrived in 1972!

C had a particular advantage, which allowed it (and Unix) to spread: it had a portable compiler. Once the compiler was ported to a new hardware platform, it could build most software which was written in it on the new platform. As Unix was rewritten in C in 1973, it spread.

Scripting languages, in the form of the Unix shell (1971), the Bourne shell (1979), and AWK came in 1977. Larry Wall’s Perl came in 1987, as a glue language for text and system administration.

Python was released in February 1991, and is of course, still in wide-spread use – having found new applications in the ML domain which no one would have anticipated at it’s birth.

Lua, PHP, Ruby and JavaScript came in the mid-90s.

In all of these abstractions, the idea was always to trade CPU efficiency for programmer efficiency. Even assembler, when translating into machine code, requires some additional compute.

Humans work best with abstractions, mnemonic symbols, and limited complexity.

The key idea, however, is that humans can work at different levels of abstraction. Different humans can specialize on different levels of abstraction. A boss does not need to understand how to code – but they are able to evaluate, whether the application is delivered on time, does what they (or marketing) want, and compare performance across teams and individual contributors.

Does it help, if the boss knows how to code? Sure, a little. But at their abstraction level, they will not NEED to.

In the same way, a modern software developer does not need to know assembler, in order to be able to write highly functional, secure, and performant code. The compilers, assemblers, linters, code hints, and Visual Studios of this world support them in their daily work. They optimize under the hood.

Of course, there are situations where hot spots need optimization. Imagine you are running a bank, which has high frequency trading algorithms. Do you want to hire experts, to squeeze every last nanosecond out of the code? Yes. You pay them top dollar, and they apply their arcane, deep knowledge, to squeeze those nanoseconds.

But does the average business application need to be optimized in every spot? Some of them would really benefit – but in general, we can afford to use a higher abstraction layer, as a trade off for some performance gains.

For big software teams, and complex projects, there are special architectural roles. These are often senior software developers, which have learned the craft, and switched to a different layer – managing other software developers, creating an architecture, ensuring that the software will continue to be manageable, translateable, etc.

A friend of mine, who runs a software development company, recently codified this. They call their product Nightshift – and it crystallizes 25 years of software development knowledge into an agentic AI platform. Reach out to us, if you want to get to know more about Nightshift.

The point I want to make is this:

Most software engineers today do not understand VHDL or Verilog (languages to describe chip designs), nor is it a necessary prerequisite for their craft.

Most software engineers do not understand the details of how the networking stack works (at a very detailed level).

There are abstractions everywhere, interfaces which hide complexity.

The right levers, and a limited amount of levers, are exposed, so that the engineers are able to control the machinery with good enough precision, to achieve the result they are aiming for.

Vibe coding, introduced in 2nd of February 2025 by Andrej Karpathy, is another step up the abstraction ladder.

Every software engineer now starts at a higher abstraction layer, without having to understand the lower abstraction layers in depth.

Over time, the interface between the layers will expose the right levers, so that engineers will be able to develop code with confidence and efficiently.

This time, the abstraction allows to describe / specify functionality in more general language, without requiring the painstaking precision which most software languages demand.

I am making several predictions here:

1. vibe coding, or better called (new term invented by me here) high abstraction coding will become mainstream
2. software developers, including novice software developers, will learn a different level of abstraction, with the goal to continue to build quality software. This includes architectural considerations, choice of libraries, the skill to craft precise spefications, and – most importantly – the skill to test the output properly.
3. a new class of linters will arise, which will check code quality, mistakes, and other problems
4. code itself might become higher-level, relying on deterministic expansion within some bounds – I expect that a new “middle” language will evolve, to which LLMs will “vibe” the code to, which then will interact with libraries, and the operating system
5. engineers will be able to read this “middle” language fluently, possibly hiding some hints which the language gives to the computer, but which are superfluous to humans. It will be optimized for readability, as opposed to writing it.
6. engineers will be able to modify the language directly, if necessary, but more often, they will use a tool modifying it, specifying in higher level abstractions
7. git and other workflows will store the engineer’s specification (the prompt), and the “middle” language. The “middle” language is the solid contract between the computer and the engineer, it is the work result. While it is at a higher level of abstraction than current languages, it will always deterministically translate to the lower level work results, which computers are able to execute directly.
8. There will be no shortage of software engineering jobs – providing software engineers understand that they are moving up the abstraction chain.

I would like to expand on point 8 in particular: The appetite comes with eating.

As the world gets a capability to write an increasing amount of software, at lower cost, more companies will be able to afford custom-built software. This will increase overall demand, provided the software is developed by an engineer who can translate customer requirements effectively into the vibe coding process. Using specialized tools, such as Nightshift.

Here at Deutsche AI Consulting, we believe in the power of higher-level abstractions, while retaining a solid and defensible approach to software engineering. Contact us today to inquire for your company vibe-coding subscription package, where we continuously develop software for you, using our rapid vibe-coding approach, while never sacrificing the safety and security of your data.