https://stephenramsay.net/posts/vibe-coding.html

If You're Going to Vibe Code, Why Not Do It in C?

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.

---------------------------------------------------------------------

Incoming: home | blog | index

Keywords: programming, AI

Last Modified: 2025-12-07T16:29:42:-0600