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

91–100 of 626 posts

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

#91

Post by colechristensen »

mavamaarten wrote: post #40
gitremote wrote: post #33

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…

Yup. I would never be able to give my Jira tickets to an LLM because they're too damn vague or incomplete. Getting the requirements first needs 4 rounds of lobbying with all stakeholders.

A significant part of my LLM workflow involves having the LLM write and update tickets for me.

It can make a vague ticket precise and that can be an easy platform to have discussions with stakeholders.

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

#92

Post by zelphirkalt »

I very much doubt the ability of LLMs to provide leak-free, faulty memory management free, C code, because they are trained on loads of bad code in that regard. They will not output code of the quality that maybe 1% of C developers could, if even that many. Fact is, that even well paid and professional C/C++ developers introduce memory management issues in such code bases (see Chromium project statistics about this). So chances to get good C programs from LLMs, which learn from far lower quality code than Chromium, are probably very slim.

Vibe-coding a program that segfaults and you don't know why and you keep burning compute on that? Doesn't seem like a great idea.

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

#93

Post by fuzztester »

iberator wrote: post #87
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.

Hehe. Try working for some telecoms dealing with gsm, umts, LTR and 5g.

or banking. or finance. or manufacturing. or $other_enterprise_lob_area.

souce: been there, done some of that.

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

#94

Post by wilg »

If you're vibe coding, I highly recommend TDD. It makes it very easy for a coding agent to iterate on it. You gotta bonk it sometimes when it tries to delete a problematic test etc, but hallucinating a test suite along with your app really helps a lot. (I've been vibe coding a scripting language/compiler for a video game project I'm working on in this way, and it's been fascinating and mostly great.)

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

#95

Post by nicoburns »

sneak wrote: post #22

I wish everyone would read this paragraph: > 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…

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

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

#96

Post by gkfasdfasdf »

vbezhenar wrote: post #37
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…

Why Rust? Haskell is gold standard here.

Can you elaborate? What is it about Haskell that makes it better?

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

#97

Post by a_wild_dandan »

swatcoder wrote: post #74
bjacobso wrote: post #50

Earlier quoted context omitted.

Claude Code et al. asks clarifying questions in plan mode before implementing. This will eventually extend to jira comments

You think the business line stakeholder is going to patiently hang out in JIRA, engaging with an overly cheerful robot that keeps "missing the point" and being "intentionally obtuse" with its "irrelevant questions"? This is how most non-technical stakeholders feel when you probe for consistent, thorough requirements and a key professional skill for many more senior developers and consultants is in mastering the soft…

Businesses do whatever’s cheap. AI labs will continue making their models smarter, more persuasive. Maybe the SWE profession will thrive/transform/get massacred. We don’t know.

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

#98

Post by tshaddox »

gitremote wrote: post #33

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…

I like my requirements articulated so clearly and unambiguously that an extremely dumb electronic logic machine can follow every aspect of the requirements and implement them "perfectly" (limited only by the physical reliability of the machine).

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

#99

Post by raphlinus »

doug_durham wrote: post #85
raphlinus wrote: post #71

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…

Proofs of what? "This new feature should make the 18 to 21 year old demographic happy by aligning with popular cultural norms". This would be difficult to formalize as a proof.

Memory safety in particular, actually UB in general (got to watch out for integer overflows, among other things). But one could prove arbitrary properties, including lack of panics (would have been helpful for a recent Cloudflare outage), etc.

In order to prove lack of UB, you have to be able to reason about other things. For example, to safely call qsort, you have to prove that the comparison is a total order. That's not easy, especially if comparing larger and more complicated structures with pointers.

And of course, proving the lack of pointer aliasing in C is extremely difficult, even more so if pointer arithmetic is employed.

Post reply on HN