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

461–470 of 626 posts

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

#461

Post by sandblast »

mrweasel wrote: post #166
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.

We had a client who'd create incredibly detailed Jira tickets. Their lead developer (also their only developer) would write exactly how he'd want us to implement a given feature, and what the expected output would be. The guy is also a complete tool. I'd point out that what he described wasn't actually what they needed, and that there functionality was ... strange and didn't actually do anything useful. We'd be told…

Maybe you'll appreciate having it pointed out to you: you should work on your usage of "where" vs "were".

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

#462

Post by godelski »

popcorncowboy wrote: post #433
jader201 wrote: post #431

Earlier quoted context omitted.

The more I know, the more I know I don’t know.

...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 don't just impress an audience, they impress an audience of magicians.

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

#463

Post by Cthulhu_ »

parasti wrote: post #171

I really tried to get into the vibe coding thing - just describe the thing I need in human language and let the agent figure it out. It was incredible at first. Then I realized that I am spending a lot of time writing clarifications because the agent either forgot or misinterpreted something. Then I realized that I am waiting an awful long time for each agent step to complete just to write another correction or clari…

One thing that helps is to write an AGENTS.md file that encodes the knowledge and tricks you have of the codebase, like running a single test (faster feedback cycles), common coding patterns, examples, etc.

I went full meta and sketched out a file, then had an expensive LLM go through the codebase and write such a file. I don't know if it's any good though, I only really use coding assistants to write unit tests.

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

#464

Post by a5c11 »

jazzyjackson wrote: post #349
dlisboa wrote: post #319

Earlier quoted context omitted.

> Then I realized that this constant start-stop process is literally melting my brain and making me unable to do any real work myself. It's basically having the same effect as scrolling any other algorithmic feed Yes, it’s extremely soul sucking. With the added disadvantage of not teaching me anything.

I felt this way too until I decided that my goal isn't to know things, it's to ship things.

Sounds very depressing.

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

#465

Post by pjmlp »

godelski wrote: post #225
omnicognate wrote: post #118

Earlier quoted context omitted.

> Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. As a Professor of English who teaches programming to humanities students, the writer has had an extremely interesting and unusual academic career [1]. He sounds awesome, but I think it's fair to suggest he may not have much experience of large scale commercial software devel…

Hard to say but to back his claim that he was programming since the 90's his CV shows he was working on stuff that's clearly more than your basic undergraduate skill level since the early 2000's. I'd be willing to bet he has more years under his belt than most HN users. I mean I'm considered old here, in my mid 30's, and this guy has been programming most my life. Though that doesn't explicitly imply experience, or m…

My first home computer was bought in 1986, before that the only electronics at home were Game & Watch handhelds, like Manhole.

I guess I am reaching Gandalf status then. :)

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

#466

Post by dwedge »

> why not do it in x86 assembly?

I was thinking that this week. We are quickly reaching a point where the quality of the code isn't as important as the test suite around it and reducing the number of tokens. High level languages are for humans to read/write, if most people aren't reading the code we should just skip this step.

It's an ugly future but it seems inevitable.

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

#467

Post by a5c11 »

TylerLives wrote: post #175
parasti wrote: post #171

I really tried to get into the vibe coding thing - just describe the thing I need in human language and let the agent figure it out. It was incredible at first. Then I realized that I am spending a lot of time writing clarifications because the agent either forgot or misinterpreted something. Then I realized that I am waiting an awful long time for each agent step to complete just to write another correction or clari…

I don't have much experience with it either, but what has worked so far is breaking down the problem into very small steps I can verify easily.

At this point it's easier to just write the code. If my prompt is to be longer than the code produced, why bother with explaining that to LLM?

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

#468

Post by pjmlp »

dwedge wrote: post #466

> why not do it in x86 assembly? I was thinking that this week. We are quickly reaching a point where the quality of the code isn't as important as the test suite around it and reducing the number of tokens. High level languages are for humans to read/write, if most people aren't reading the code we should just skip this step. It's an ugly future but it seems inevitable.

This is a point I keep advocating, sure the tools aren't yet there, but it is foolish to assume we don't ever get there, generating 3GL source code is only a transition step.

We already are having visual programming tools with AI agents, with various kinds of success, see iPaaS like Boomi, Workato and similar.

Recently I have had the opportunity to be part of projects using such kind of tools.

If there is any traditional coding it is a bunch of serverless endpoints exposed as MCP tools.

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

#469

Post by pjmlp »

kgeist wrote: post #393
badRNG wrote: post #170

Earlier quoted context omitted.

> Speaking of vibe coding in archaic languages Well, I think we can say C is archaic when most developers write in something that for one isn't C, two isn't a language itself written in C, or three isn't running on something written in C :)

If we take the most popular programming languages and look at what their reference (or most popular) implementations are written in, then we get: C++: JavaScript (V8), Java, C# C: Python, PHP, Lua, Ruby Self-hosted: Go, Rust Far from archaic indeed. We're still living in the C/C++ world.

Java and C# compilers are selfhosted.

Then depending on which JVM implementation we are talking about the actual JVM runtime can be Java, C, or C++, or a mix of them.

Modern C compilers are written in C++.

Rust uses LLVM, written in C++.

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

#470

Post by pjmlp »

tmtvl wrote: post #400
kgeist wrote: post #393

Earlier quoted context omitted.

If we take the most popular programming languages and look at what their reference (or most popular) implementations are written in, then we get: C++: JavaScript (V8), Java, C# C: Python, PHP, Lua, Ruby Self-hosted: Go, Rust Far from archaic indeed. We're still living in the C/C++ world.

I thought Rust still used LLVM (a C++ project) for the backend, did they already switch to Cranelift?

No, it is still LLVM.
Post reply on HN