Live data from Hacker News

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

stephenramsay.net

121–130 of 626 posts

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

#121
> Or hell, why not do it in x86 assembly?

I do vibe code in C; I'm not a C programmer and I certainly couldn't do a security audit of any serious C codebase, but I can read and understand a simple C program, and debug and refactor it (as long as it's still quite simple).

And it's super fun! Being able to compile a little C utility that lives in the Windows tray and has a menu, etc. is exhilarating.

But I couldn't do that in assembly; I would just stare at instructions and not understand anything. So, yes for C, no for assembly.

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

#122

Earlier quoted context omitted.

If AI doesn't make you more productive you're using it wrong, end of story. Even if you don't let it author or write a single line of code, from collecting information, inspecting code, reviewing requirements, reviewing PRs, finding bugs, hell even researching information online, there's so many things it does well and fast that if you're not leveraging it, you're either in denial or have ai skill issues period.

My company mandates AI usage and logs AI usage metrics as input to performance evaluation, so I use it every day. It's a Copilot subscription, though.

why though? are they just using it as a proxy for "is 'gitremote' working today?"

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

#123

Earlier quoted context omitted.

If AI doesn't make you more productive you're using it wrong, end of story. Even if you don't let it author or write a single line of code, from collecting information, inspecting code, reviewing requirements, reviewing PRs, finding bugs, hell even researching information online, there's so many things it does well and fast that if you're not leveraging it, you're either in denial or have ai skill issues period.

Not to refute your point but I’ve met overly confident people with “AI skills” who are “extremely productive” with it, while producing garbage without knowing, or not being able to tell the difference.

You're describing lack of care and lack of professionalism, fire these people, nothing to do with the tools, it's the person using it the problem.

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

#124
post #108

> Why vibe code with a language that has human convenience and ergonomics in view? Recently I've been preparing a series that teaches how to use AI to assist with coding, and in preparation for that there's this thing I've coded several times in several different languages. In the process of that, I've observed something that's frankly bizarre: I get a 100% different experience doing it in Python vs C#. In C#, the ag…

This kind of meets with my experience - AI tends to follow specific patterns for each language, earlier this year I was finding that AI was presenting me with 4 different approaches to a problem, none of them were working so it would cycle through each of the four approaches.

I lost a day chasing my tail cycling through those 4 approaches, but the experience was worthwhile (IMO) because I had beeen becoming lazy and relying on AI too much, after that I switched to a better style of using AI to help me find those approaches, and as a sounding board for my ideas, whilst staying in control of the actual code.

(Oh, I should also mention that AI's conviction/confidence did cause me to believe it knew what it was talking about when I should have backed myself, but, again, experience is what you get after you needed it :)

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

#125
post #101

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.

It’s not a super useful line of inquiry to ask “why” LLMs are good at something. You might be able to come up with a good guess, but often the answers just aren’t knowable. Understanding the mechanics of how LLMs train and how they perform inference isn’t sufficient to explain their behavior a lot of the time.

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

#126
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…

That's a really, really interesting point.

It makes me imagine a programming language designed for LLMs but not humans, designed for rigorous specification of every function, variable, type, etc., valid inputs and outputs, tightly coupled to unit tests, mandatory explicit handling of every exception, etc.

Maybe it'll look like a lot of boilerplate but make it easy to read as opposed to easy to write.

The idea of a language that is extremely high-effort to write, but massively assists in guaranteeing correctness, could be ideal for LLM's.

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

#127

At that point, why not develop a custom language or IL that is specifically designed for LLM use and which compiles to good native code? I propose WASM, or an updated version of it

Because LLMs will have no concept of that IL. It only have a model for what it has seen.

100%

People are still confusing AI putting together scraps of text it has seen that correlates with its understanding of the input, with the idea that AI understands causation, and provides actual answers.

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

#128

Earlier quoted context omitted.

If AI doesn't make you more productive you're using it wrong, end of story. Even if you don't let it author or write a single line of code, from collecting information, inspecting code, reviewing requirements, reviewing PRs, finding bugs, hell even researching information online, there's so many things it does well and fast that if you're not leveraging it, you're either in denial or have ai skill issues period.

It sounds like you're the one in denial? AI makes some things faster, like working in a language I don't know very well. It makes other things slower, like working in a language I already know very well. In both cases, writing code is a small percentage of the total development effort.

No I'm not, I'm just sick of these edgy takes where AI does not improve productivity when it obviously does.

Even if you limit your AI experience to finding information online through deep research it's such a time saver and productivity booster that makes a lot of difference.

The list of things it can do for you is massive, even if you don't have it write a single line of code.

Yet the counter argument is like "bu..but..my colleague is pushing slop and it's not good at writing code for me", come on, then use it at things it's good at, not things you don't find it satisfactory.

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

#130

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.

How does the LLM get all the required knowledge about the domain and the product to ask relevant questions?
Post reply on HN