The Inevitability of Vibecoding

Why nobody cares if their chatbot can even write correct code.

March 30, 2026

In the world of software development, I am an anomaly.

I don’t use syntax highlighting, meaning my code doesn’t colour itself based on its structure. I don’t use a debugger, so I need to test my code carefully from a more holistic perspective. I don’t use code suggestions or completions, instead requiring me to look up function names from a manual if I fail to recall them. I don’t use a file system gutter in my code editor, which makes it more difficult for me to manage a large number of folders and files in my projects. I don’t copy code from Q&A sites like StackOverflow, in part because I prefer to understand my own code and because I choose to use languages and code libraries which are not popular enough to get others to ask questions that I would later need answers to.

I’m happy with my approach. I can’t simply coast by and expect my tools to do most of the work for me. I need to actually slow down and spend a lot of time thinking about the problems I want to solve than I do actually writing the code to solve the issues. My approach has led me to becoming possibly the expert in writing GNOME software in Lua—not a terribly impressive accomplishment but I’ve reached it all the same.

Still, my programming style was like this long before I started using GNOME, and longer still before I picked up Lua as my language of choice. I simply cannot work with tools that provide me too much information for me to handle. The flipside of this is that I have an uncommon appreciation for high-quality code, the kind which is easy to read, which is so simple that it is obviously correct, which is so minimal in scope that it’s unlikely to have security holes. The upside of solving problems with less code is that the result creates fewer problems of its own.

This is not the normal approach to software development, which treats the task as being about writing as much code as possible until the problem appears solved. Syntax highlighting lets the user be sure that they’re writing code which will compile without needing to actually compile, suggestions lets the user brute-force their way through using a library (even their own), file sidebars allow the user to see all their work at a glance (even when such glances are unnecessary), etc. A lot of developer tooling has historically been about empowering the developer to move fast and cope with increasing amounts of code. When writing code hastily, quality and correctness matter a lot less. When code is written sloppily, then further comprehension of code becomes more difficult. A programmer in this situation will find themselves tempted to use more and more complicated tooling to manage the complexity they have wrought onto themselves. It’s a positive feedback loop; When too much code has been written to be able to adequately manage, the only obvious solution to someone taking this approach is to indulge in further excess.

Many software developers, particularly free software developers, have lamented the current state of software development as a whole. Many of our colleagues are happily allowing chatbots to write code in their name, barely giving a thought to the code being output, exhibiting zero regard for soundness, correctness, or even whether the resulting software even works in the first place. In the words of one of these developers, they have wholly surrendered to the vibes.

It was only on reflection of my own place in this world of software development that I have come to realize: vibecoding is not new. For decades, software developers have looked for ways to write code with no effort, to act as though they’ve done work without exerting the effort required to actually do real work, to feel like they’ve accomplished something while only ever putting out software that is virtually identical in form and function to their own inspirations.

Do you critique vibecoding on the grounds that it is functionally incapable of delivering anything that is both novel and correct? It’s a fair critique, but I think it would’ve been fitting to say of most software developers decades ago. The history of IDEs, object-oriented programming, modular programming, and more is a history of trying to squeeze as much code out of a programmer as if that’s the part of software development that matters, to the detriment of actually putting real effort into understanding problems, solutions, and code itself.

I have known vibecoders long before the term had been coined. That these sorts, who once extruded thousands of lines of code per day, have handed the reins to chatbots with no regard for anything meaningful should ultimately not surprise anyone. The surrendering of developer cognition over to language models which are fundamentally unfit to solve problems should then not come as a surprise, because the culture of software development rotted away a long time ago.

The good news is that “AI” companies are not long for this world. Trillions of dollars of investment have yet to yield a profit, and these imaginary profits will not come to fruition before investment money runs out. Open source models will not buoy the vibecoder after this bubble bursts either, because none will remain who will be able to absorb the cost of training unprofitable future language models for software development. Even in the fiscally impossible event that the bubble somehow doesn’t burst, vibecoding will so thoroughly pollute future code training datasets that the eventual result will be total model collapse. This, too, has been the destiny of the code-first mentality; When you prioritize creating technical debt over anything else, there will one day come a time when those debts must be repaid.

Vibecoding was inevitable. The end of vibecoding will also be inevitable.