Feeling the Vibe

Vibing, changes everything

It’s 0430, and though I am on a conference call with staff from the East Coast of the US, I’m also vibing. I can’t help myself; never have I had so much power to create almost any software I can dream of, with not just a little boast, but with 80%, 90%, or even 95% all done via vibing, prompt-based engineering.

If you think this is hyperbole, it isn’t. Last week, I created, in a day, a fully implemented server-side reverse proxy that applies user scripts to websites on the fly; in 11 hours—eleven hours of just me, my MacBook, and ChatGPT, Claude, Kilo, and Codex. This would have taken me in the past, and I know this as I have written a similar piece of software before, more than a month.

I used to think that I loved to code, and perhaps that is still true, but what this has shown me is that my true love is to create.

But like everything else in Computer Science, when a new innovation comes, there are many downstream consequences. Many of which I have not seen mentioned in any of the usual suspects blogs, videos, or articles.

Programming Languages

Programming languages for the back-end are dead, put a fork in them. I’m serious, “They’re dead, Jim.” Why? Think about it: languages like FORTRAN were created in the 1950s. OK, yes, Plankalkül was technically created in the 1940s, but does anyone really remember it? And why were they created? To make machine code readable to software engineers, as tools to make programming easier. And these languages, tools, that we have created from FORTRAN to Rust to Java and everything in between, slow down the processing device they run on as they become more and more abstracted above the actual hardware that is doing that work. You are not going to get anywhere near the performance in some higher-level language than if you just have the code all in assembly, doing individual processor instructions like MOV R0, R2.

Keep in mind assembly isn’t compiled, it’s assembled into pure machine code.

So, do we really need programming languages? I just spent an hour vibing and having all the output in ARM assembly. You want to talk about fast code, it’s mind-blowing. I can hear the language lovers saying, “But Jason, you can’t really read assembly, it’s so complicated and difficult.” First, I can read assembly, but why do I need to read it? I can just ask, pick your vibe engine with inference, what does this code mean? Some might argue that a professional developer then needs to make tweaks that the vibe coding tool missed, and my answer is, “Learn a little assembly or have the tool teach you, it isn’t hard.”

But, but, but libraries, modules, includes, package managers... seriously, why do you need them? Your vibing tool can assemble everything you need, all together. All of these mechanisms, dragging in libraries, OOP, you don’t need any of it anymore. Use the vibe tool and then your professional developer skills to make amazing, incredibly performant, far lower memory use services.

What about web programming? Vibe programming is going to take us back to HTML, CSS, and JavaScript, the end. No libraries, frameworks, none of it. React.js, done. And all for the same reasons, the server-side code is going back to its roots with vibing, these languages and frameworks were all created, from Dojo (I get a little sick every time I even think of Dojo) to jQuery to Angular to React, for the explicit purpose of making web software engineering faster and easier; as tools for the developer. With vibe coding, why in the world would you need them? And don’t forget all those tools make the browser slower, bloated, and continually lead to my blessed tabs in Chrome using more memory than the first computer I had that could open a webpage.

Server Operating Systems

Operating Systems for servers; they are going to be like Old Marley, dead as a doornail. I can hear it now, but we need operating systems for drivers to talk to keyboards, and video cards, accessing memory and I/O, scheduling, multitasking, file system access... and I would counter with, why? Operating Systems create tremendous overhead for servers. If I can build a piece of software that is designed to run a specific workload, mostly using vibe tooling, then why do I need a general-purpose operating system to do all of these things, of which I might need, for a specific workload, maybe 10%?

Let me give you an example. Remember that reverse proxy server I wrote using Vibe coding? I have it running, right now, on a single-board ARM64 computer. It is not running any operating system at all, just a bootloader and my proxy code, both of which were 80-90% created with Vibe coding. I don’t need to connect to the keyboard, mouse, I/O, GPU, or, for that matter, much of anything. I just need for the reverse proxy application, access to the network card, done with Vibing, memory management, Vibing, file system, Vibing, and that’s it. I wrote my own threading and scheduling, AArch64, with Vibing, that is tailor-made to proxy REST payloads.

And I did this in hours, and it screams. It is using all of the hardware available, custom fit specifically for the purpose. Low cost, low power consumption, and I have not been able to with my various workstations scattered about, running workload simulations, to break it. It just keeps performing.

Think about what this means. Viruses on the server, they are over, this application is running directly on the hardware; you literally can’t install anything else. It only knows how to run my proxy program. Patching and managing operating systems, a herculean task that automation and DevOps professionals have to engage in, ummm, patch what? Crash, the program will just restart; it’s running in a loop. There is no operating system, only Zuul. OK, I know, but I had to have a Ghostbusters reference in this article.

Software and Software Companies

This is going to sound like heresy, since I am the CTO of a division of a software company. But software companies, as they are currently constituted, are going the way of the dodo. Not because anyone now can make super complicated applications like ERPs just by Vibing, you are going to need lots of highly skilled software engineers to work with the Vibing toolchain, but because the speed at which software can be created with Vibing is so fast that end-users and companies will not need or want general-purpose software.

As a company, why do I need an SAP, as an example, which, while a great ERP system, and more, does probably 80% more than what I need; and isn’t exactly inexpensive? With Vibing, I can get a perfectly custom ERP system that does literally exactly what I want and need, at a fraction of the cost, running bare metal on less expensive to buy and operate hardware. Why in the world would I buy a general-purpose ERP system, or a CRM, or SCM, HRMS, and more when I can have all of those perfectly tailored to my needs for less money?

With Vibing, the future of software companies is going to be, in the words of one of my bosses (look, if you are going to be the CTO of a large software division, you are going to end up like Paul Wilson in Office Space, with lots of bosses), Services as Software. Companies are going to contract with these new-age software companies for specific solutions to their exact needs. And these new-age software companies are going to use highly skilled software engineers with Vibing to create, support, and evolve these curated, individual applications for the customer. No company in its right mind five years from now, is going to be buying general-purpose enterprise software. And software companies today that don’t rapidly evolve in this direction, providing services as software, are going to be dinosaurs.

This all may sound scary, or crazy . . . perhaps even both. But to me, it is exciting. Heck, it is thrilling. Change is a universal constant in Computer Science. And every time there has been a change in my tenure on this globe, there has been opportunity. This is the time to grab on with both hands and get Vibing.