Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

stephenramsay.net

Post reply on HN
Print view View original

591–600 of 626 posts

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

#591

Post by keeda »

lunar_mycroft wrote: post #581
keeda wrote: post #286

Earlier quoted context omitted.

> - Most devs who say AI speeds them up assert numbers much higher than what those studies have shown. I am not sure how much is just programmers saying "10x" because that is the meme, but if at all realistic numbers are mentioned, I see people claiming 20 - 50%, which lines up with the studies above. E.g. https://news.ycombinator.com/item?id=45800710 and https://news.ycombinator.com/item?id=46197037 > - Prior to LLM…

> if at all realistic numbers are mentioned, I see people claiming 20 - 50% IME most people claim small integer multiples, 2-5x. > all the largest studies I've looked at mention this clearly and explain how they try to address it. Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so. > My current hypothesis, based on the DORA and DX 2025 reports, is that…

> Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so.

That's not quite true: while everybody acknowledged it was folly to measure absolute individual productivity, there were aggregate metrics many in the industry were aligning on like DORA or the SPACE framework, not to mention studies like https://dl.acm.org/doi/abs/10.1145/3540250.3558940

Similarly, many of these AI coding studies do not look at productivity on an individual level at a point of time, but in aggregate and over an extended period of time using a randomized controlled trial. It's not saying Alice is more productive than Bob, it's saying Alice and Bob with AI are on average more productive than themselves without AI.

> They claim that this won't impact quality because of the aforementioned review and their QA process. Do you think that's a realistic assessment? If and on the off chance you think it is, why didn't this happen on a larger scale pre-LLM?

Interestingly, I think something similar did happen pre-LLM at industry-scale! My hypothesis (based on observations when personally involved) is that this is exactly what allowed offshoring to boom. The earliest attempts at offshoring were marked by high-profile disasters that led many to scoff at the whole idea. However companies quickly learned and instituted better processes that basically made failures an exception rather than the norm.

I expand a bit more and draw parallels to coding with AI here: https://news.ycombinator.com/item?id=44944717

> ... as is the fact that LLM generated code is still worse than human generated...

I still don't think that can be assumed as a fact. The few studies I've seen find comparable outcomes, with LLMs actually having a slight edge in some cases, e.g.

- https://arxiv.org/abs/2501.16857

- https://arxiv.org/html/2508.00700v1

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

#592

Post by nicoburns »

tptacek wrote: post #321
nicoburns wrote: post #95

Earlier quoted context omitted.

> It creates robust, complex systems that work Do you have any examples of these? All the vibe coded systems I've seen so far were very far from robust.

2025 called and wants your argument back.† https://news.ycombinator.com/item?id=45549434 † this is a joke; i feel it works on multiple levels

I'm not sure I get the joke, but the project reference is interesting - thanks!

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

#593

Post by sureglymop »

gbin wrote: post #494
sureglymop wrote: post #259

Earlier quoted context omitted.

Lately I have learned assembly more deeply and I sometimes let an AI code up the same thing I did just to compare. Not that my own code is good but every single time assembly output from an optimizing compiler beats the AI as it "forgets" about all the little tricks involved. However it may still be about how I prompt it. If I tell it to solve the actual challenge in assembly it does do that, it's just not good or ef…

Shouldn't we try vibe coding on IR then? Basically assembly before compiler optimizations?

Yeah I suppose one would need not only the source and binaries but also the IR in AI training data which may be rare but could probably be easily generated for a lot of software.

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

#594

Post by lmm »

lomase wrote: post #488
lmm wrote: post #329

Earlier quoted context omitted.

Idiomatic Rust prevents many classes of logic errors. Just having proper sum types eliminates many (perhaps most) common logic errors.

Idiomatic Java too.

Not my experience. For example the "official" way of achieving the equivalent of sum types (the visitor pattern) is so verbose that idiomatic Java tends to use the equivalent of a "single table inheritance" style instead of proper domain modelling, which inevitably leads to all sorts of logic errors. Idiomatic Java uses "magic" AOP because the alternatives are too verbose, but this also inevitably causes logic errors (indeed in some ways it's worse than C where you'd do the equivalent thing with a preprocessor macro, which is at least a bit more visible in the code even if only due to conventions like UPPERCASE names). What kind of logic errors are seen in C that you would claim that idiomatic Java avoids?

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

#595

Post by perrygeo »

stared wrote: post #5

There was a recent discussion, “Why AI Needs Hard Rules, Not Vibe Checks” ( https://news.ycombinator.com/item?id=46152838 ). We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding. Without checks and feedback, LLMs can easily generate unsafe code. So even if they can generate C or Assembly that wor…

> abstraction isn’t only for humans; it’s also for LLMs.

Bingo. LLMs are language models, not models of software systems. Everything gets translated through natural language! So the quality of the abstraction still matters: code that can be described well in plain language wins.

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

#596

Post by jcelerier »

swatcoder wrote: post #81
jcelerier wrote: post #47

Earlier quoted context omitted.

To be honest I've never worked in an environment that seemed too complex. On my side my primary blocker is writing code. I have an unending list of features, protocols, experiments, etc. to implement, and so far the main limit was the time necessary to actually write the damn code.

That sounds like papier mache more than bridge building, forever pasting more code on as ideas and time permit without the foresight to engineer or architect towards some cohesive long-term vision. Most software products built that way seem to move fast at first but become monstrous abominations over time. If those are the only places you keep finding yourself in, be careful!

The vision is "being compatible with protocols used in my field". There's hundreds over hundreds of those. Example: this app supports more than 700 protocols, hardware, etc. (https://bitfocus.io/connections) and still it's missing an AWFUL LOT and only handles fairly basic cases in general. There's just no way around writing the code for each custom bespoke protocol for whatever $APPLIANCE people are going to bring and expect to work. Even if each protocol fits neatly in a single self-contained class or two.

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

#597

Post by adamzwasserman »

bobbylarrybobby wrote: post #555
adamzwasserman wrote: post #553

Practical argument for vibe coding in C: the training corpus is probably much higher quality. C code that survives in the wild tends to be written by experienced devs who care about correctness. The JS corpus includes mountains of tutorial code, Stack Overflow copypasta, and npm packages with 3 downloads. In my experience, generated C is noticeably better—and this might be why.

How well can LLMs reason about avoiding UB? This seems like one of those things where no matter how much code you look at, you can still easily get wrong (as humans frequently do).

Fair point on UB — LLMs absolutely do not reason about it (or anything else). They just reproduce the lowest-common-denominator patterns that happened to survive in the wild.

I’m not claiming the generated C is “safe” or even close. I am sure that in practice it still has plenty of time-bombs, but empirically, for the narrow WASM tasks I tried, the raw C suggestions were dramatically less wrong than the equivalent JavaScript ones — fewer obvious foot-guns, better idioms, etc.

So my original “noticeably better” was really about “fewer glaring mistakes per 100 lines” rather than “actually correct.” I still end up rewriting or heavily massaging almost everything, but it’s a better starting point than the JS ever was.

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

#598

Post by anuramat »

throwuxiytayq wrote: post #549
whiatp wrote: post #253

Earlier quoted context omitted.

Something I've noticed that I never really see called out is how easy it is to review rust code diffs. I spent a lot of my career maintaining company internal forks of large open source C programs, but recently have been working in rust. The things I spent a lot of time chasing down while reviewing C code diffs, particularly of newer team members, is if they paid attention to all the memory assumptions that were non-…

How do LLMs deal with Rust (compared to other languages)? I think this might actually be the time to finally give the language a try. LLMs really lowered the barrier for staying productive while learning.

sometimes they randomly choose the ugliest possible way to do pattern matching, eg multiple blocks of nested "if let" instead of a "match", or a "match" instead of a single "if let"

otherwise, works great; much easier to un-vibe the code compared to eg python

(gpt 5.* in codex/sonnet 4.5 in cc/glm 4.6)

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

#599

Post by Aeolun »

godelski wrote: post #462
popcorncowboy wrote: post #433

Earlier quoted context omitted.

...and the more I know you don't know. [On the disappearance of wizards as you age]

Both definitely contribute. But at the same time the people who stay wizards (and the people you realize are wizards but didn't previously) only appear to be more magical than ever. Some magic tricks are unimpressive when you know how they are done. But that's not true for all of them. Some of them only become more and more impressive, only truly being able to be appreciated by other masters. The best magic tricks do…

I think as I gain more experience, what previously looked like magic now always turns out to look a whole lot more like hard work, and frustration with the existing solutions.

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

#600

Post by atilaneves »

tome wrote: post #527
atilaneves wrote: post #481

Earlier quoted context omitted.

I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock. So...yeah.

How did your tests pass if you didn't handle state?

Because it is also possible to write tests that don't adequately capture real-life requirements.

It was an MQTT server, and the tests basically went "if we have these subscriptions, then...", but no subscriptions ever got actually stored by the server.

Post reply on HN