Introduction

As Vibe Coding becomes a daily practice for many developers, we may sense that software development is entering a new paradigm. In this context, the author poses a provocative question: If you are already relying on AI to write code, why not use C? Or even x86 assembly? If future code is meant for machines, do our current programming languages, readability, and syntactic sugar still hold meaning? Is there a need for a programming language specifically designed for AI generation, a “Vibe-Oriented Programming Language”?

Personal Reflections on Vibe Coding

I have a thought: if you are already Vibe Coding, why not just use C? Or, more boldly, jump straight to x86 assembly?

Before diving into this seemingly absurd idea, let me clarify a few key points—I am serious, not mocking.

First, I personally do not favor Vibe Coding (coding by feel or entirely generated by AI). I have loved programming since I first encountered it in the late 1990s. For me, writing code has always felt like a job that doesn’t feel like work—it’s just too much fun. It’s both my profession and my hobby.

As the saying goes, “Do what you love, and you will never work a day in your life”—that’s how I feel when I code.

I have been teaching programming for 25 years and have never grown tired of it. I still feel excited for the first class every semester. Teaching someone who cannot code to become a coder is my career and my proudest achievement as a university professor.

However, Vibe Coding feels strange to me, even a bit “dirty.” I don’t mean to imply it’s cheating (though it does have that flavor); rather, it robs the joy of programming. I often tell students that programming is like the best crossword puzzle in the world—when you get it right, it really “sings.” But Vibe Coding takes away that sense of accomplishment—because the program wasn’t written by me; I didn’t “crack” that puzzle.

Worse yet, as a programmer, you are supposed to coexist with various uncertainties: Do you think you understand the inner workings of the compiler? Maybe; do you think you truly grasp the virtual memory system? Possibly. While I can’t give definitive answers, I still want to understand every line of code I write, rather than suffer through incomprehensible code generated by Claude.

The Viability of Vibe Coding

But this leads to the second key point: Vibe Coding is indeed feasible; it can produce robust, complex, and runnable systems. You might, like me, initially believe that “AI cannot do this”—but that’s incorrect; you might think it’s merely a “substitute search engine” for programming problems—this is also wrong.

When you start handing over those little programs you’re too lazy to write yourself, you’ll find it remarkably capable. Until one day, you casually mention to the AI model, “I have a program idea…” and you will be completely amazed by its output. If you weren’t amazed, either you haven’t seriously tried it, or you haven’t accepted reality.

Is AI-generated code perfect? Far from it. But human-written code isn’t perfect either. Is this the future? I think the answer is obvious.

Programming Languages for Humans

Let’s return to the seemingly absurd idea in the article title.

When I first got into programming, I read “Structure and Interpretation of Computer Programs” (SICP) and considered it one of the greatest programming textbooks of the 20th century. There’s a passage I’ve always remembered—second paragraph of the preface:

“We hope to establish the idea that programming languages are not just tools for computers to perform operations; they are also formal media for expressing methodological ideas. Therefore, programs are primarily written for humans to read, with the machine execution being a secondary concern.”

Since then, I have instilled various versions of this idea in my students. I remind them that computers don’t care whether code is “readable” or “user-friendly” for humans; they only need the code to be parseable and executable—this threshold is much lower than “human comprehensibility.”

Every programming language, even assembly language, is designed for “humans.” Innovations in language are not due to features like automatic memory management, concurrency, safety, or error checking, but because they allow “humans” to express and organize these technical logics more easily.

When we praise Rust’s safety, C++’s zero-cost abstractions, or Go’s concurrency model… ultimately, these capabilities are conveniences for “human programmers,” not for computers. For computers, our “object-oriented obsession” is merely an inexplicable fixation on heap memory: “You can do whatever you want.” (Computers might think this way.)

In fact, whether it’s functional programming, algebraic data types, dependent types, immutable data structures, or code block styles… these are all “human ergonomics issues.” Compared to “machine engineering problems,” human issues are far more complex.

Why Not Let AI Output Machine-Friendly Languages?

So, my question arises:

Since you are already Vibe Coding, why stick to languages designed for human convenience?

In other words: shouldn’t what AI generates be the most machine-friendly language? Why not let it write C directly? Or wouldn’t generating x86 assembly code be more straightforward?

You might counter, “But we still need to understand the code."—Fine, but note: if you are truly Vibe Coding, you probably don’t understand most of the AI-generated code anyway. Moreover, if you observe closely, you’ll find that AI doesn’t fear undefined behavior in C; it can also handle memory deallocation properly and is less prone to “errors.” It can execute logic more correctly than you, just as a compiler optimizes better than you. Is it perfect? Certainly not. But as I mentioned earlier, nobody achieves perfection.

So, is C the best language for Vibe Coding? Maybe not. But I know Rust is definitely not suitable, and Haskell, OCaml are even less so, as these languages are written for “humans” and not for “AI.” In fact, they might seem a bit “cute” in front of AI models—considering too many problems that AI doesn’t even face.

The Need for a New Vibe-Oriented Language

What I want to express is this: If Vibe Coding is indeed the future of software development, why cling to languages designed for “humans”? Shouldn’t we create a “Vibe-Oriented Programming Language” (VOPL)?

You might be hearing this concept for the first time.

What could this VOPL look like?

1. A super powerful “pseudocode” language, which presents easy-to-understand pseudocode on the surface while quietly generating assembly instructions behind the scenes.
2. A true implementation of “literary programming,” where you write a document explaining “methodological ideas,” and AI directly produces machine code, with the programmer’s core work becoming validating the AI-generated machine code (even test cases are written by AI).
3. A language close to natural language but with specific programming jargon, which is closer to natural language than any existing language while having a set of easily grasped idiomatic expressions, guiding AI to provide solutions more accurately and efficiently.

However, the reality is that the reason AI code models excel at JavaScript and C++ is that they have learned billions of lines of code in these two languages, along with countless forum posts, discussions on StackOverflow, and related data. Therefore, building and promoting a VOPL is challenging.

But some speculate that LLMs are already learning some future version of VOPL—after all, many programmers are now using Vibe Coding to build production-level systems, akin to crossing the river by feeling the stones.

My Thoughts on This Future

If I had to describe this future in one word, it would be: complex.

The thought that “handwritten code” might become the introductory course for future Vibe Coders, akin to a fun introduction in kindergarten, makes me a bit sad; but on the other hand, a new computational paradigm is emerging, which excites me.

From a macro perspective, not long ago (around 1945 during the ENIAC era), people only realized how inefficient it was to rewire for every calculation; and when the stored-program computer (around 1951 with EDVAC) appeared, there were also complaints about it being “unreliable, slow, depriving operators of participation, threatening professionalism, and not pure enough.”

Today, our heated debates seem remarkably similar to those of the past.