If you're going to vibe code, why not do it in C?

> 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?

Or why not just produce a binary directly? It seems we've just invented a compiler.

No need for using assembler, LLMs should be writing machine bits directly into executables. It is also fairly simple to teach them how to do it. Provided we have some executable that was written in some human-readable computer language. We can read through the bits of the executable, and describe each portion using English, based on the description of what the original human-readable language is doing. This new model will only learn the English representation of chunks of bits and how they go together into an executable. After learning several billion such narrated executables it will be excellent at writing machine code.

Honestly, I think this is a valid viewpoint, but perhaps C is too low level. The bottleneck in generating code with LLMs tends to happen at the validation step. Using a language that has a lot of hard to validate footguns isn't great.

While I am not a big fan of Rust, the philosophy is likely useful here. Perhaps something like it, with a lot of technical validation pushed to the compiler, could actually be really useful here.

Getting rid of the garbage collector with no major increase in human cognitive load might actually be a big win.

I've vibe coded a few things in C now as experiments, but I haven't been brave enough to put any of them into production code yet. I don't trust myself to review them properly.

C extensions for SQLite: https://simonwillison.net/2024/Mar/23/building-c-extensions-...

This one is closest to something I might use because it's C compiled to WebAssembly, so the blast radius for any dumb bugs is strictly limited: https://github.com/simonw/research/blob/main/cmarkgfm-in-pyo...

The main benefit of C is that it is especially readable by humans.

I think that’s what makes it so common in codebases that have long term maintenance stories.

(I say that because my personal project has me reading great loads of C written by diverse authors and I am surprised at how easy it is to figure out, compared to most other languages)

I think this is an odd idea. For a lot of reasons, but one is simply that higher level languages _tend_ to be terser, and context window matters for LLMs. Expressing more in less is valuable.

I’ve had a similar (likely non original) thought too that eventually LLMs could lead to something more akin to a compiler that would take human language instructions and go straight to a executable binary, possibly even with more traditional compiler analysis for performance and safety etc.

But then again LLMs in their current form are trained on mountains of human language so maybe having them output human readable code makes sense at least for now

> 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.

… well, you are wrong.

I recently gave the "vibe" AI the assignment of "using GTK [4, I think], establish a global shortcut key".

No amount of massaging the prompt, specifying the version of GTK, etc. could prevent it from just outright hallucinating the functions it wanted to call into existence. The entire reason I was asking was because I did not know what function to call, and was having difficulty discerning that from GTK's documentation. (I know how to do this now, and it is effectively undocumented.)

Prior to that, an assignment to determine some information from Alembic. Again, the AI desired to just hallucinate the functions it required into existence.

A script to fetch the merge queue length from GH. It decided to call GH's GraphQL API, which is fine, and doable for the task, but the query was entirely hallucinated.

A bash script to count files change in git. The code ran, and the output was wrong. The author did not check the LLM's code.

Even non-programming tasks are the same. Image generation is a constant fight of trying to get the AI to understand what you mean, or it just ignoring your prompts, etc. I went about 10 prompts trying to get an image with a stone statue of 4 ASCII characters in a field. The last character was consistently just wrong, and no amount of prompting to fix.

"Generate a character with a speech bubble that says 'Hi'" -> speech bubble has Japanese in it! (And the Japanese is gibberish, but if you ask AI to translate it, it "will".)

AI generated code is filled with bugs. No language is as unforgiving about bugs as C is.

"I also think it takes a lot of the fun out of the whole thing."

Agreed. It's like replacing a complex and fulfilling journey with drugs.

Re: love of programming - those who think an AI should do it all should consider whether they should outsource having sex as well.

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

Or assembly, or binary

Yes, this is a completely valid take and it is the ultimate answer to why vibe coding, the way most people define vibe coding is a dead end.

The point is we want the LLM to generate code that is first and foremost readable by humans and structured in such a way that a human can take over control at any time.

If you think this is how LLM should generate code, congratulations we are already in agreement.

If you think programmers should not exist and that you will help your bottom line by reducing the number of programmers on your payroll or worse, completely eliminate programmers from your payroll by paying product managers who will never ever look at the code (which is required for vibe coding the way I understand it), then this question at the top is for you.

Many of the “no” comments here are very focused on the current state. The author seems to be looking at a longer time horizon of computing paradigms, for example invoking ENIAC. On that scale I tend to agree. Vibe coding has only been around a year or two and look how big of an impact it already has. Imagine what another 10 years of progress will look like.

Traditionally, I used Python for personal tools optimizing for quick coding and easy maintenance. These tools commonly feed UI elements like waybar, shell, and tmux, requiring frequent, fast calls.

My approach is evolving due to NixOS and home-manager with vibe coding to do the lifting. I increasing lean on vibe coding to handle simple details to safely write shell scripts (escaping strings, fml) and C/C++ apps. The complexity is minimized, allowing me to almost one-shot small utilities, and Nix handles long-term maintenance.

With NixOS, a simple C/C++ application can often replace a Python one. Nix manages reading the source, pulling dependencies, and effectively eliminating the overhead that used to favor scripting languages while marking marginal power savings during everyday use.

I think the author glosses over a core problem AI would need to overcome for his thoughts to become reality: training data.

We can't teach AI to code in languages that do not have human ergonomics because, as of now, all AI is based on human example.

There’s a nugget of an idea in there, even if I disagree with most of it.

But code doesn’t only need to be understood for maintenance purposes: code is documentation for business processes. It’s a thing that needs to be understandable and explainable by humans anytime the business process is important.

LLMs can never / should never replace verifiability, liability, or value judgment.

Idk why the author thinks that C would be a better language than Rust for vibe coding. Intuitively, I would have thought that the more formal constraints the system imposes, the better for vibe coding (since the more powerful static checks make it harder to write incorrect code).

Of course in practice I think the author is actually correct - LLM's struggle more than humans with sophisticated formal constraints and less than humans with remembering to write a bunch of boilerplate. But I think it's a pretty counterintuitive result and I'd love to have seen more discussion of it.

There's a straightforward answer to the "why not" question: because it will result in codebases with the same kind of memory unsafety and vulnerability as existing C code.

If an LLM is in fact capable of generating code free of memory safety errors, then it's certainly also capable of writing the Rust types that guarantee this and are checkable. We could go even further and have automated generation of proofs, either in C using tools similar to CompCert, or perhaps something like ATS2. The reason we don't do these at scale is that they're tedious and verbose, and that's presumably something AI can solve.

Similar points were also made in Martin Kleppmann's recent blog post [1].

[1]: https://martin.kleppmann.com/2025/12/08/ai-formal-verificati...

"If you ask PMs about backend requirements, they will dodge you, and if you ask front-end or web developers, they are waiting for you to provide them the API. The hardest part is understanding the requirements. It's not because of illiteracy. It's because software development is a lot more than coding and requires critical thinking to discover the requirements."

IF this is true, you have bad PMs.

Why should it be the case that LLMs are equally comfortable in x86 Assembly and Python? At least, it doesn't strike me as implausible that working in a human-readable programming language is a benefit for an LLM that is also trained on a bunch of natural language text alongside code.

Obviously right now the best language to use LLMs for, vibe coding or not, is whatever they are most familiar with, although not sure what this actually is! Java?

Going forwards, when LLMs / coding tools are able to learn new languages, then languages designed for machines vs humans certainly makes sense.

Languages designed for robust error detection and checking, etc. Prefer verbosity where it adds information rather than succintness. Static typing vs dynamic. Contractual specification of function input/output guarantees. Modular/localized design.

It's largely the same considerations that make a language good for large team, large code base projects, opposite end of the spectrum to scripting languages, except that if it's machine generated you can really go to town on adding as much verbosity is needed to tighten the specification and catch bugs at compile time vs runtime.

If you want to get to a higher level compiler, prompt fondling will not suffice; you need to master formal specification. Then machine learning algorithms can do the program synthesis to implement the spec. But just talking out your vague software requirements with a chatbot is not analogous to programming.

Also, like others said, even once you have your formal spec, C is a particularly bad choice (unless you want to specify quite a bit more). You want the program implemented in a language with as many safety constraints on it as possible, not one where you have to mentally track memory.

I wish I could convey my thoughts that well!

On the topic: I feel like we still need at least a few more innovations in the space before we can rely on them to work in areas where we as humans still have trouble (that pesky training data!). Even when providing documentation, I still find LLMs to often have trouble creating code in newer versions of libraries.

My biggest fear with LLMs is that it will steer a lot of development into a more homogenous space over time (even just with the types and versions of libraries it chooses when vibing).

I want to do my vibe coding in a dependently typed language, so that at least I can tell what the inputs and outputs are. I say Idris is the future!

Or... I want to only write the tests. The implementation is... an implementation detail!

It is interesting though that if it's all the same anyway - why not write formally proved software. Or write the same spec in three different languages to cross check correctness.

I've wondered what vibe codings impact is to language development, whereas C vs LISP had their tradeoffs when deciding what to use. If everything is vibecoded (not saying it will be) everything probably normalizes to javascript

  > Thus, programs must be written for people to read, and only incidentally for machines to execute

On fun/joy in the era of agency - https://bikeshedding.substack.com/p/the-agency-continuum

If you’re going to vibe code, why not do it in Brainfuck?

Claude hilariously refused to rewrite my rails codebase in Brainfuck…not that I really expected it to. But it went on a hilarious tirade about how doing so was a horrible idea and I would probably fired if I did.

I have been coding as an autodidact for 20 years now. In the past months, I have been vibe coding a lot, with multiple AIs at the same time. I have achieved to code a full webapp (React and Next.js for the front, RestJS for the back) in five days. Refactoring, adding features and writing the right tests for everything to work has been procuring me with the same problem solving and endorphin kicks as usual programming. Just don't vibe code something which you could do yourself, maybe that is the issue of the author.

> Why vibe code with a language that has human convenience and ergonomics in view?

Because you would not be able to audit the code if you don't (you'll be terribly slow to read and understand the inner flows correctly and that's if these aren't so bad that would do you some brain damage).

Dang, AI is pushing us all to become managers.

I started reading this out of curiosity, thinking: that's such a far fetched thought, I'm curious about what the author wants to say. I think he makes a good point about execution vs. readability, and the actual need for the latter, drawing analogies to earlier abstractions. I'm still skeptical about low level language generation (tbh, letting an LLM handle memory at this point of maturity feels scary to me.. leaks etc)... But overall very interesting writeup and many points that I agree with.

The premise: If people drive drunk already, why not give them even faster cars with less road stability and worse brakes?

I sincerely hope the author is joking.

Why not do it in English? I have a "program" that exists entirely as the history of an AI chatbot session. To "run the program" I load the history and a file into the message context and say "Now do this file." It kind of reminds me of a Smalltalk VM in a weird way.

I have been developing a game with this process, specifically for portability, reach and distribution across multiple game engines and platforms.

I find CUX to be very intuitive for prototyping. But my game is Language and HCI at heart, logic that allows the development process to go smoothly. It is certainly not for everyone or every project.

Along the same lines, I am rewriting a React Native app into native Swift and Kotlin versions. I haven’t written any of the native code directly - it’s all vibed. It’s not C but there’s a lot of upside in letting Claude Code compile my wishes into native languages and skip the RN layer.

If the LLMs of today can even produce a sizable C program that compiles, doesn't leak memory, doesn't exhibit UB, doesn't have any obvious vulnerabilities, and is correct, I would be astounded.

Looks like a bad fit to me, it's very freeform and genAI does really badly with consistency and coherence

C is actually pretty good, if you can manage to architect your project cohesively

It doesn't have problems with undefined behavior, memory safety, or especially thread safety?

That has not been my experience when using Codex, Composer, Claude, or ChatGPT.

Things have just gotten to the point over the last year that the undefined behavior, memory safety, and thread safety violations are subtler and not as blindingly obvious to the person auditing the code.

But I guess that's my problem, because I'm not fully vibing it out.

>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

I was really hoping you were going to make this argument, based upon the title of the piece! Still a good read, but if you have the inclination I hope you loop back around to weighing the pros and cons of vibe coding in different languages

"You can do everything in C"

Including shooting yourself in the foot.

/Rust

ive been vibe coding (i think it's vibe coding) in C for the past three weeks and it's been super fun. i was tasked with trying to improve our highly optimized hyper-graph partitioning algorithm. One of the fun things i like to do is feed the llm an academic paper, have it summarize the key pts, and then implement the algos that we (me and the llm) find interesting. This feels like i hit the fabled 10x productivity mark because it would have taken me at least a week (probably more) to digest a paper enough to implement it, and often I would give up, convincing myself it's not worth the time / effort. So 10x might even be a low ball.

Context limit and build time are a couple of reasons. There is C++ code at work I told it to rewrite in Python just to make it easier to vibecode (or regular code) after. Granted, it had no good reason to be in C++ in the first place.

> 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.

Tons of people make the above claim and tons of other people make the exact opposite claim that it’s just a search engine and it can’t actually code. I’m utterly shocked at how two people can look at ground truth reality and derive two different factual conclusions. Make no doubt one of these two people is utterly wrong.

The only thing I can conclude is many people are either in denial or outdated. A year ago none of what this man said was true.

> 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.

Then show us this robust, complex code that was produced by vibe coding and let us judge for ourselves.

Because, the programming languages best matched to a (natural human language-based) declarative programming paradigm (e.g., vibe coding) would be declarative programming languages, not imperative programming languages.

I guess vibe coding is fun as a meme, but it hides the power of (what someone else on HN) called language user interfaces (LUIs).

The author's point is correct IMO. If you have direct mappings between assembly and natural language, there's no functional need for these intermediate abstractions to act as pseudo-LUIs. If you could implement it, you would just need two layers above assembly: an LLM OS [1], and a LUI-GUI combo.

However, I think there's a non-functional, quality need for intermediate abstractions - particularly to make the mappings auditable, maintainable [2], understandable, etc. For most mappings, there won't be a 1:1 representation between a word and an assembly string.

It's already difficult for software devs to balance technical constraints and possibilities with vague user requirements. I wonder how an LLM OS would handle this, and why we would trust that its mappings are correct without wanting to dig deeper.

[1] Coincidentally, just like "vibe coding", this term was apparently also coined by Andrej Karpathy.

[2] For example, good luck trying to version control vectors.