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

71–80 of 626 posts

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

#71

Post by raphlinus »

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

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

#74

Post by swatcoder »

bjacobso wrote: post #50
mavamaarten wrote: post #40

Earlier quoted context omitted.

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.

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 skills that keep them attentive and sufficiently helpful. Those skills are not generic sycophancy, but involve personal attunement to the stakeholder, patience (exercising and engendering), and cycling the right balance between persistence and de-escalation.

Or do you just mean there will be some PM who acts as proxy between for the stakeholder on the ticket, but still needs to get them onto the phone and into meetings so the answers can be secured?

Because in the real world, the prior is outlandish and the latter doesn't gain much.

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

#75

Post by gitremote »

legitster wrote: post #53
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…

Convince your PMs to use an LLM to help "breadboard" their requirements. It's a really good use case. They can ask their dumb questions they are afraid to and an LLM will do a decent job of parsing their ideas, asking questions, and putting together a halfway decent set of requirements.

PMs wouldn't be able to ask the right questions. They have zero experience with developer experience (DevEx) and they only have experience with user experience (UX).

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

#76

Post by nu11ptr »

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…

It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside. I mean C doesn't even have a builtin hashtable or vector, let alone pattern matching, traits and sum types. I get this is about AI and vibe coding, but we aren't at a point yet where zero human interaction is reasonable, so every code base should assume some level of hybrid human/AI involvement. Why people want so badly to start a new code base in C is beyond me (and yes, I've written a lot of C in my time, and I don't hate it, but it didn't age well in expressiveness).

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

#78

Post by shortrounddev2 »

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 write a library which is used by customers to implement integrations with our platform. The #1 thing I think about is not

> How do I express this code in Typescript?

it's

> What is the best way to express this idea in a way that won't confuse or anger our users? Where in the library should I put this new idea? Upstream of X? Downstream of Y? How do I make it flexible so they can choose how to integrate this? Or maybe I don't want to make it flexible - maybe I want to force them to use this new format?

> Plus making sure that whatever changes I make are non-breaking, which means that if I update some function with new parameters, they need to be made optional, so now I need to remember, downstream, that this particular argument may or may not be `undefined` because I don't want to break implementations from customers who just upgraded the most recent minor or patch version

The majority of the problems I solve are philosophical, not linguistic

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

#79

Post by jedbrooke »

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

Post reply on HN