Live data from Hacker News

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

stephenramsay.net

611–620 of 626 posts

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

#611

Earlier quoted context omitted.

Following similar thinking, there's no world in which AI becomes exactly capable of replacing all software developers and then stops there, miraculously saving the jobs of everyone else next to and above them in the corporate hierarchy. There may be a human, C-suite driven cost-cutting effort to pause progress there for some brief time, but if AI can do all dev work, there's no reason it can't do all office work to r…

> if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard There are plenty of reasons. Radiologists aren’t being replaced by AI because of liability. Same for e.g. civil engineers. Coders don’t have liability for shipping shit code. That makes switching to an AI that’s equally blameless easier. Also, data: the web is first and foremost a lot of code. AI i…

> Coders don’t have liability for shipping shit code

Depends on the industry, and shipping shit code is the reason cybersecurity laws are starting to be a thing.

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

#612
Thinking about the programming language as a first requirement when vibe coding is probably not the smartest move. The programming language choice (beyond being fit for your purpose) is how prevalent it is in the training data for the model (more examples for what you want to achieve -> better results). When vibe coding the most important things are to know how to spec what you want to achieve and how you measure the results. The programming language is just a tool.

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

#613
post #396

Earlier quoted context omitted.

Why would you think its more complex? There are less permutations of generating transistor on/off states than there are all the different programming languages in use that result in the exact same bits. Who said that creating bits efficiently from English to be computed by CPUs or GPUs must be done with transformer architecture? Maybe it can be, maybe there are other ways of doing it that are better. The AI model arc…

> Why would you think its more complex? Binary code takes more space, and both training and inference is highly capped by memory and context sizes. Models tokenize to a limited set of tokens, and then learn relations between those. I can't say for sure, but I feel it be more challenging to find tokenization schemes for binary code and learn their relationships. The model needs to first learn human language really wel…

Diffusion models for images are already pretty much binary code generators. And we don't need to treat each bit individually, even in binary code there are whole segments that can be tokenized into a single token.

Regarding training, we have many binaries all around us, for many of them we also have the source code in whichever language. As a first step we can use the original source code and ask a third party model to explain what it does in English. Then use this English to train the binary programmer model. Eventually the binary programmer model can understand binaries directly and translate them to English for its own use, so with time, we might not even need binaries that have source code, we could narrate binaries directly.

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

#614
post #52

I see a lot of "vibe-coding" related articles, but I don't see a lot of shipped projects/products via "vibe-coding". I would like to find some examples instead of this kind of articles ?

Yesterday I released a Rust-with-Python-bindings package that was mostly coded with Claude 4.5 Opus: https://github.com/minimaxir/icon-to-image I'll write about the process after I've released a few more things as I have some disagreements with the current discourse.

That's more interesting, how much were you involved personally in writing the code ? I would love to read about the process !

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

#615

Earlier quoted context omitted.

> if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard There are plenty of reasons. Radiologists aren’t being replaced by AI because of liability. Same for e.g. civil engineers. Coders don’t have liability for shipping shit code. That makes switching to an AI that’s equally blameless easier. Also, data: the web is first and foremost a lot of code. AI i…

> Coders don’t have liability for shipping shit code What if you're shipping code for a therac-25?

That's actually a terrific example, because the company already had a working, field-tested manually controlled version of their product, but they wanted a computer-controlled version to relieve radiologists of all of the drudgery and opportunities for error in the manual setup. So the design spec was to "faithfully replicate the manual setup procedures in a microcontroller," which was achieved. The problem was that the UI was utter dogshit, the training materials were poor (you can't have Marketing say "hey this computer handles all the details for you!" and then expect customers to pore page-by-page through the reference manual), and most clinics weren't really enforcing or QAing the operator training anyway. And since "the computer has a handle on it," the radiologists and senior techs who were supposed to be second-checking everything basically abdicated that responsibility, driven in part I'm sure by management that expected them to now have more "free hours" for other activities that Make Line Go Up. And nobody really raised a flag that this seemed troubling until multiple children died, and at the end of the day a lot of people could say "well, it wasn't my fault, I did what I was told to do" and sort of believe it.

If anyone doesn't think all of that is going to happen again on a massive scale as companies embrace GenAI, HAHAHAHAHAHAHA. AI will change a lot of things, but it won't fix human nature.

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

#616

Earlier quoted context omitted.

It is still possible to write bugs in both Haskell and Rust.

Yes, that's my point. I'm replying to claims that "if it compiles it probably works". My limited experience with both is "nah".

I prefer the slogan without "probably", "If it compiles it works", because then at least it's clear it's a slogan and not a formal claim. Everyone knows that if you write

    multiply x y = x + y
then it will compile but not work, so they don't take it literally. But it is a pithy statement of the lived experience of many users of strongly typed programming, which is more accurately described by something like "if it compiles then it will probably do something at least basically sensible and often be pretty close to what you actually wanted".

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

#617

Earlier quoted context omitted.

I wish you the best of luck, truly. But I have written C in the past, it was almost 20 years ago, and everything seemed to work fine, until the memory leaks. Of course today I would ask the AI, why is my program leaking memory. I think you have a point, AI would be sort of like having a mentor help you find bad practices in your C code. You've inspired me to maybe try my hand at Rust, something I've been wanting to d…

Would something like automated array bounds checking prevent the memory issues?

You might be interested in AddressSanitizer.

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

#618

Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. I work in backend, API development, which is completely different from fullstack development with backend development. If you ask PMs about backend requirements, th…

> In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements.

Totally agree. I’ve tried to explain this in many places: AI coding (and creative tools in general) will ultimately remain tools. Only people who can clearly and thoughtfully articulate requirements will be able to fully leverage them.

Another hot take: the “one-person company.” Headcount isn’t the key variable. With AI, the real constraint is how well you can understand a problem and clearly define a solution.

- If a problem can be clearly defined and fully understood by one person, then one person is enough to solve it.

- If a problem is more complex and requires two fundamentally different areas of expertise, then it will likely take two capable people to solve it—no more, no less.

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

#619

Earlier quoted context omitted.

Burden of proof is on you sir, not the other way around.

There is no proof for things that haven't happened yet. I just find the belief that the continuous rapid improvements in machine intelligence stopping just short of human intelligence quite arbitrary.

The definition of what we see progress in with LLMs as anything akin to intelligence is your supposition, though.

It's a view I don't share at all. I don't see anything that could be even remotely considered intelligent under any reasonable definition of the term. Useful in places, yes. Intelligence, hard no. So the question of whether it will approch or surpass human intelligence makes no sense to me, because the technology and its progress are in an entirely different dimension and unrelated to that idea or goal.

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

#620

Earlier quoted context omitted.

Following similar thinking, there's no world in which AI becomes exactly capable of replacing all software developers and then stops there, miraculously saving the jobs of everyone else next to and above them in the corporate hierarchy. There may be a human, C-suite driven cost-cutting effort to pause progress there for some brief time, but if AI can do all dev work, there's no reason it can't do all office work to r…

> if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard There are plenty of reasons. Radiologists aren’t being replaced by AI because of liability. Same for e.g. civil engineers. Coders don’t have liability for shipping shit code. That makes switching to an AI that’s equally blameless easier. Also, data: the web is first and foremost a lot of code. AI i…

> Coders don’t have liability for shipping shit code.

Yet another reason why this needs to change, fast.

Post reply on HN