Live data from Hacker News

A guide to Gen AI / LLM vibecoding for expert programmers

stochasticlifestyle.com

41–50 of 122 posts

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#41

It's hardly original, but my take is that vibe coding works brilliantly for personal projects (or potentially for tiny startups that need to rapidly churn out CRUD boilerplate, API integrations, etc), but terribly for most large commercial systems. I'm having fun with Claude Code and Vibe Kanban on personal projects, and before that I spent a lot of time with both the Windsurf and Cursor agents. It's making me litera…

if we have to put numbers on it, I'm attempting projects I wouldn't have, because the startup cost was too high, so does that make me infinity times more productive on that project because the denominator otherwise would have been zero?

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#43

This illusion that senior engineers are too good to fall in all the traps laid by vibe coding really needs to stop. Just yesterday I was reading the comment of a Principal Engineer saying "of course vibe coding carries a huge risk for more junior engineers that don't understand when the LLM does something that looks right but is actually wrong", as if just because they have more experience THEY CAN. No, you can't eit…

> Not a single soul on this planet can review the thousands of lines of vibe coded bullshit that LLMs spit out. Even if you could the code can't be copyrighted.

Citation needed on that one.

If that is true, how come huge companies like Microsoft and Salesforce and Google keep boasting about the increasing percentage of their code that is written by LLMs?

What do you know that they don't?

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#44
post #26

I think the article could be more accurately titled "A Guide to Gen AI / LLM Vibecoding for Programmers who hate their job" To me, someone who actually love programming, it makes vibe coding look like hell. > The workflow of vibe coding is the same as managing scrums or helping a student through a research thesis Which programmer wants that?! Just hearing the word "scrum" makes me want to run away and I know I am not…

almost every job ive ever had has been to build stuff. frequently programming is used to build stuff. programming is not my job, building stuff is. it’s perfectly normal (and a sign of a more mature engineer, imho) to prefer building stuff to the annoying stuff that gets in the way of building stuff, especially since many languages are obnoxious to work with.

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#45
post #19

Earlier quoted context omitted.

New generations are always leapfrogging those that came before them, so I don't find it too hard to believe even under more pessimistic opinions of LLM usefulness. They are young and inexperienced today, but won't stay that way for long. Learning new paradigms while your brain is still plastic is an advantage, and none of us can go back in time.

But automating isn't a programming paradigm. > They are young and inexperienced today, but won't stay that way for long. I doubt that. For me this is the real dilemma with a generation of LLM-native developers. Does a worker in a fully automated watch factory become better at the craft of watchmaking with time?

[deleted]

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#46
post #26

I think the article could be more accurately titled "A Guide to Gen AI / LLM Vibecoding for Programmers who hate their job" To me, someone who actually love programming, it makes vibe coding look like hell. > The workflow of vibe coding is the same as managing scrums or helping a student through a research thesis Which programmer wants that?! Just hearing the word "scrum" makes me want to run away and I know I am not…

I think I enjoy programming. Vibe coding removes most of the parts that I like. It already looks like hell. I'm probably a minority, but I don't think I'm alone in this.

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#47
post #16
post #6

Earlier quoted context omitted.

You underestimate how much code some people have sifted through in their lifetime. I read through every line the LLM codes, function by function. I know exactly when it’s going sideways. You’d have to know to even know, it’s one of those things. If you don’t know then you don’t know. Put it another way, you know how some people fail open book tests? How’s that possible? The book is not enough.

I found that once I spend enough time to actually fully understand what LLM wrote, I’ve burned through my efficiency gains. If that’s the case, why bother?

Because I’m not just trying to get efficiency gains. I’m literally trying to build next gen products of good quality.

I suppose for your actual job (if you happen to be in the IDGAF mode), yeah, why work harder and not smarter? That’s a different story altogether, as many will be mailing it in.

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#48

I always wonder what kind of slop people are creating when they say they have a bajillion Claude instances all churning out code.

In my experience you would not be able to identify code I wrote by hand from code I generated with an asynchronous agent, because I wouldn’t let it get to you if something stood out as off.

But I don’t “vibe code” anything. I understand and review all the code that gets generated. Most of the stuff coming from my agents is either boilerplate or extensively uses libraries and static analysis tools that make it easy to verify.

I kill aggressively any code the agent outputs that doesn’t match my standards unless it’s obvious that I can get it up to par quickly. This is one of the big advantages of the llm. I can do that without navigating inter personal conflict.

But the output is mostly indistinguishable from what I create by hand.

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#49

Earlier quoted context omitted.

So, why would you review thousands of lines at a time? That means you didn't break the problem down appropriately. PRs should be around 100-200 lines of code, including tests. You build your tasks appropriately. Reviewing thousands of lines at a time is always a failure state.

The number of lines you have to review at once doesn't matter. Vibe coding is letting AI write code so you spend less time writing the same amount of code (ideally not more, in practice definitely more). If more code is written you have to review more code. Doesn't matter if you break it down in 10 lines PRs or if you review a million lines at once, you still end up having to review all the code generated.

It entirely matters. It matters because as humans, we can only keep so much context in mind. That means that if you are looking at 100-200 lines at a time, you can think about the architecture. You can modify the code, whether it's fixing or refactoring. It means that it can only get too far off base.

It also means that sometimes, you say "this is bad code," refine the prompt, and run it again.

Yes, it means that you as a code reviewer is a bottleneck. It means that you are limited to the productivity gain that can exist. We are talking 10-15% productivity gains per person in mature code bases, not some magic replacement.

But if you're worried about reviewing code, maybe we shouldn't allow junior programmers to contribute to codebases either. After all, you might make a mistake in reviewing that.

Re: A guide to Gen AI / LLM vibecoding for expert programmers

#50

It's hardly original, but my take is that vibe coding works brilliantly for personal projects (or potentially for tiny startups that need to rapidly churn out CRUD boilerplate, API integrations, etc), but terribly for most large commercial systems. I'm having fun with Claude Code and Vibe Kanban on personal projects, and before that I spent a lot of time with both the Windsurf and Cursor agents. It's making me litera…

if we have to put numbers on it, I'm attempting projects I wouldn't have, because the startup cost was too high, so does that make me infinity times more productive on that project because the denominator otherwise would have been zero?

Same here, my numbers come from "how much progress do I make with a single day spent working on a given project".

Previously: make a little bit of progress, realize I'd need a year's worth of weekends to complete it, give up after one day.

With vibe-coding assistance: make 10x+ progress, realize that with a few more weekends I could finish it, keep going.

Post reply on HN