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

511–520 of 626 posts

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

#511

Post by JumpCrisscross »

sdiupIGPWEfh wrote: post #495
pron wrote: post #238

Earlier quoted context omitted.

The thing is that some imagined AI that can reliably produce reliable software will also likely be able to be smart enough to come up with the requirements on its own. If vibe coding is that capable, then even vibe coding itself is redundant. In other words, vibe coding cannot possibly be "the future", because the moment vibe coding can do all that, vibe coding doesn't need to exist. The converse is that if vibe codi…

Following similar thinking, there's no world in which AI becomes exactly capable of replacing all software developers and then stops there, miraculously saving the jobs of everyone else next to and above them in the corporate hierarchy. There may be a human, C-suite driven cost-cutting effort to pause progress there for some brief time, but if AI can do all dev work, there's no reason it can't do all office work to r…

> if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard

There are plenty of reasons.

Radiologists aren’t being replaced by AI because of liability. Same for e.g. civil engineers. Coders don’t have liability for shipping shit code. That makes switching to an AI that’s equally blameless easier.

Also, data: the web is first and foremost a lot of code. AI is getting good at coding first for good reason.

Finally, as OP says, the hard work in engineering is actually scoping requirements and then executing and iterating on that. Some of that is technical know-how. A lot is also political and social skills. Again, customers are okay with a vibe-coded website in a way most people are not with even support chatbots.

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

#512

Post by aswegs8 »

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…

Good news for you: average age on HN is 42

https://news.ycombinator.com/item?id=33480849

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

#513

Post by chamomeal »

crazygringo wrote: post #126
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…

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 la…

Feel like you can also achieve pretty correct programs using good tests. Like really good tests.

I’m thinking of generative tests (quickcheck style), fuzzing, erroring on invariants, contract testing (see the test.contract clojure library for a very cool contract test setup!).

Really really good test suites can do stuff that even logically verified programs can’t do. They’re just a pain in the ass to write. Seems like a good use of LLMs, and you can keep using the same languages!

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

#515

Post by theptip »

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…

> very few people can correctly articulate requirements

The observation from Lean is that the faster you can build a prototype, the faster you can validate the real/unspoken/unclear requirements.

This applies for backends too. A lot of the “enterprise-y” patterns like BFFs, hexagonal, and so on, will make it really easy to compose new APIs from your building blocks. We don’t do this now because it’s too expensive to write all the boilerplate involved. But one BFF microservice per customer would be totally feasible for a sales engineer to vibe code, in the right architecture.

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

#516

Post by tomorgan »

I expect this has been said before, but why not do it in whatever language you think has been written about the most, with the greatest amount of referenceable data and examples. Which probably isn't assembly, and probably not C either.

Which will probably store up a problem for the future, with an outsized amount of programs written in languages that were popular on SO when models started learning...

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

#517

Post by throwforfeds »

0xbadcafebee wrote: post #293
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…

If it needs that many rules, why use AI at all? Linters pre-exist AI, don't cost money, and don't boil the oceans. Look at Shellcheck. It turns a total newbie into a shell master just by iteration.

I find it's really nice to just have Claude run the compilers and linters when it's done making a change, as it often has some mistakes and will catch them at this step. It lets me step in for review after some trivially stupid thing is fixed up, rather than wasting my own time.

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

#519

Post by Thorrez »

Danborg wrote: post #486

Vibe coding should be done in Python, and probably only in Python. If a project is important enough to require C or x86 assembly, where memory management and undefined behavior have real consequences, then it’s important enough to warrant a real developer who understands every line. It shouldn’t be vibe coded at all. Python’s “adorable concern for human problems” isn’t a bug here, it’s a feature. The garbage collecti…

Vibe coded Python can certainly have security holes too.

If you want a language that protects you from the largest amount of problems, how about Rust? Vulnerabilities will still be possible, but at least data races won't be possible.

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

#520

Post by MetaWhirledPeas »

lisbbb wrote: post #390
MetaWhirledPeas wrote: post #311

Earlier quoted context omitted.

> very few people can correctly articulate requirements This is the new programming. Programming and requirements are both a form of semantics. One conveys meaning to a computer at a lower level, the other conveys it to a human at a higher level. Well now we need to convey it at a higher level to an LLM so it can take care of the lower-level translation. I wonder if the LLM will eventually skip the programming part a…

My solution as a consultant was to build some artifact that we could use as a starting point. Otherwise, you're sitting around spinning your wheels and billing big $ and the pressure is mounting. Building something at least allows you to demonstrate you are working on their behalf with the promise that it will be refined or completely changed as needed. It's very hard when you don't get people who can send down requi…

> I very seldom ran into people who could articulate what they needed

The people with the needs and ideas are often so divorced from the "how" that they don't even bother trying to nail down the details. I think in their mind they are delegating that to the specialists.

This question of who writes the requirements is so ubiquitous you would think we'd have better solutions for it. I know some people solve it with processes like BDD but personally I think we'd be better off if we just had clearer role definitions.

For example, in a waterfall project the requirements usually land in the lap of the Business Analyst. Well when you look at Business Analyst roles you see they are expected to do a lot more than documenting requirements, so it's viewed as acceptable when they are somewhat bad at it. They also spend most of their time with the business so they are unaware of the limitations of the team who is expected to implement the changes.

For another example look at Scrum. It talks a lot about good requirements in the form of user stories, but it stops short of assigning this responsibility to any one of the formal roles, presumably making it a team activity or expecting it to be organic.

When we want someone to write code we hire a programmer, and writing code is what they are expected to do. Where is the role that is strictly requirements and nothing else? Considering how often I hear complaints about bad requirements, it seems overdue that we establish one.

Post reply on HN