Stephen Ramsay
Or hell, why not do it in x86 assembly?
Let’s get a few things out of the way before I go any further with this seemingly impertinent thought, because it’s nowhere near as snarky as it sounds.
First, I don’t particularly like vibe coding. I love programming, and I have loved it since I made my first tentative steps with it sometime back in the mid-to-late 90s. I love programming so much, it always feels like I’m having too much fun for it to count as real work. I’ve done it professionally, but I also do it as a hobby. Someone apparently once said, “Do what you love and you’ll never work a day in your life.” That’s how I feel about writing code. I’ve also been teaching the subject for twenty-five years, and I can honestly say I am as excited about the first day of the semester now as I was when I first started. I realize it’s a bit precious to say so, but I’ll say it anyway: Turning non-programmers into programmers is my life’s work. It is the thing of which I am most proud as a college professor.
Vibe coding makes me feel dirty in ways that I struggle to articulate precisely. It’s not just that it feels like “cheating” (though it does). I also think it takes a lot of the fun out of the whole thing. I sometimes tell people (like the aforementioned students) that programming is like doing the best crossword puzzle in the world, except that when you solve it, it actually dances and sings. Vibe coding robs me of that moment, because I don’t feel like I really did it at all. And even though to be a programmer is to live with a more-or-less permanent set of aporias (you don’t really understand what the compiler is doing, really—and even if you do, you probably don’t really understand how the virtual memory subsystem works, really), it’s satisfying to understand every inch of my code and frustrating—all the way to the borderlands of active anxiety—not quite understanding what Claude just wrote.
But this leads me to my second point, which I must make as clearly and forcefully as I can. Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong. You can then tell yourself (as I did) that it’s good as a kind of alternative search engine for coding problems, but not much else. You are also wrong about that. Because when you start giving it little programming problems that you can’t be arsed to work out yourself (as I did), you discover (as I did) that it’s awfully good at those. And then one day you muse out loud (as I did) to an AI model something like, “I have an idea for a program…” And you are astounded. If you aren’t astounded, you either haven’t actually done it or you are at some stage of grief prior to acceptance. Perfect? Hardly. But then neither are human coders. The future? I think the questions answers itself.
But to get to my impertinent question…
Early on in my love affair with programming, I read Structure and Interpretation of Computer Programs, which I now consider one of the great pedagogical masterpieces of the twentieth century. I learned a great deal about programming from that book, but among the most memorable lessons was one that appears in the second paragraph of the original preface. There, Hal Abelson and Gerald Sussman make a point that hits with the force of the obvious, and yet is very often forgotten:
[W]e want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
I’ve been repeating some version of this to my students ever since. Computers, I remind them, do not need the code to be “readable” or “ergonomic” for humans; they only need it to be readable and ergonomic for a computer, which is a considerably lower bar.
Every programming language—including assembly language—was and is intended for the convenience of humans who need to read it and write it. If a language is innovative, it is usually not because it has allowed for automatic memory management, or concurrency, or safety, or robust error checking, but because it has made it easier for humans to express and reason about these matters. When we extol the virtues of this or that language—Rust’s safety guarantees, C++’s “no-cost abstractions,” or Go’s approach to concurrency—we are not talking about an affordance that the computer has gained, but about an affordance that we have gained as programmers of said computer. From our standpoint as programmers, object-oriented languages offer certain ways to organize our code—and, I think Abelson and Sussman would say, our thinking—that are potentially conducive to the noble treasures of maintainability, extensibility, error checking, and any number of other condign matters. From the standpoint of the computer, this little OO kink of ours seems mostly to indicate a strange affinity for heap memory. “Whatevs!” (says the computer). And pick your poison here, folks: functional programming, algebraic data types, dependent types, homoiconicity, immutable data structures, brace styles… We can debate the utility of these things, but we must understand that we are primarily talking about human problems. The set of “machine problems” to which these matters correspond is considerably smaller.
So my question is this: Why vibe code with a language that has human convenience and ergonomics in view? Or to put that another way: Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? Why not have it just write C? Or hell, why not x86 assembly?
Now, at this point, you will want to say that the need for human understanding isn’t erased entirely thereby. Some version of this argument has merit, but I would remind you that if you are really vibe coding for real you already don’t understand a great deal of what it is producing. But if you look carefully, you will notice that it doesn’t struggle with undefined behavior in C. Or with making sure that all memory is properly freed. Or with off-by-one errors. It sometimes struggles to understand what it is that you actually want, but it rarely struggles with the actual execution of the code. It’s better than you are at keeping track of those things in the same way that a compiler is better at optimizing code than you are. Perfect? No. But as I said before…
Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal. To say nothing of Haskell, or OCaml, or even Python. All of these languages, after all, are for people to read, and only incidentally for machines to execute. They are practically adorable in their concern for problems that AI models do not have.
I suppose what I’m getting at, here, is that if vibe coding is the future of software development (and it is), then why bother with languages that were designed for people who are not vibe coding? Shouldn’t there be such a thing as a “vibe-oriented programming language?” VOP. You read it here first.
One possibility is that such a language truly would be executable pseudocode beyond even the most extravagant fever dreams of the most earnest Pythonistas; it shows you what it’s doing in truly pseudo code, but all the while it’s writing assembly. Or perhaps it’s something like the apotheosis of literate programming. You write a literary document “expressing ideas about methodology,” and the AI produces machine code (and a kind of literary critical practice evolves around this activity, eventually ordering itself into structuralist and post-structuralist camps. But I’m getting ahead of myself). Perhaps your job as a programmer is mostly running tests that verify this machine code (tests which have also been produced by AI). Or maybe a VOPL is really a certain kind of language that comes closer to natural language than any existing programming language, but which has a certain (easily learned) set of idioms and expressions that guide the AI more reliably and more quickly toward particular solutions. It doesn’t have goroutines. It has a “concurrency slang.”
Now obviously, the reason a large language model focused on coding is good at Javascript and C++ is precisely because it has been trained on billions of lines of code in those languages along with countless forum posts, StackOverflow debates, and so on. Bootstrapping a VOPL presents a certain kind of difficulty, but then one also suspects that LLMs are already being trained in some future version of this language, because so many programmers are already groping their way toward a system like this by virtue of the fact that so many of them are already vibe coding production-level systems.
I don’t know how I feel about all of this (see my first and second points above). It saddens me to think of “coding by hand” becoming a kind of quaint Montessori-school stage in the education of a vibe coder—something like the contour drawings we demand from future photoshopers or the balanced equations we insist serve as a rite of passage for people who will never be without a calculator to the end of their days.
At the same time, there is something exciting about the birth of a computational paradigm. It wasn’t that long ago, in the grand scheme of things, that someone realized that rewiring the entire machine every time you wanted to do a calculation (think ENIAC, circa 1945) was a rather suboptimal way to do things. And it is worth recalling that people complained when the stored-program computer rolled around (think EDVAC, circa 1951). Why? Well, the answer should be obvious. It was less reliable. It was slower. It removed the operator from the loop. It threatened specialized labor. It was conceptually impure. I’m not kidding about any of this. No less an authority than Grace Hopper had to argue against the quite popular idea that there was no way anyone could ever trust a machine to write instructions for another machine.
Same vibe, as the kids say.
Keywords: programming, AI
Last Modified: 2025-12-07T16:29:42:-0600