Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A guide to Gen AI / LLM vibecoding for expert programmers

stochasticlifestyle.com

Post reply on HN
Print view View original

61–70 of 122 posts

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

#61

Post by lubujackson »

lagrange77 wrote: post #25
Retr0id wrote: 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?

I think the idea that LLMs are just good at "automating" is the old curmudgeon idea that young people won't have.

I think the fundamental shift is something like having ancillary awareness of code at all but high capability to architect and drill down into product details. In other words, fresh-faced LLM programmers will come out the gate looking like really good product managers.

Similar to how C++ programmers looked down on web developers for not knowing all about malloc and pointers. Why dirty your mind with details that are abstracted away? Someone needs to know the underlying code at some point, but that may be reserved for the wizards making "core libraries" or something.

But the real advancement will be not being restricted by what used to be impossible. Why not a UI that is generated on the fly on every page load? Or why even have a webform that people have to fill out, just have the website ask users for the info it needs?

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

#62

Post by afro88 »

> The moment you see it go off the rails, just throw it out. That problem is too hard for Claude, it’s for you now.

Or, any of:

- the problem was too big in scope and needed a stepped plan to refer to and execute step by step

- your instructions weren't clear enough

- the context you provided was missing something crucial it couldn't find agentically, or build knowledge of (in which case, document that part of the codebase first)

- your rules/AGENTS.md/CLAUDE.md needs some additions or tweaking

- you may need a more powerful model to plan implementation first

Just throwing away and moving on is often the wrong choice and you'll get better at using these tools slower. If you're still within the "time it would have taken me to do it myself" window, think about what caused it to go off the rails or fail spectacularly and try giving it another go (not following up, throw away current results and chat and try again with the above in mind)

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

#63

Post by simonw »

bobsmooth wrote: post #30

Trying to get better at vibe coding is like trying to get better at sleeping. The whole point is not to put effort into it.

I completely disagree, for both definitions of vibe coding (the unreviewed-prompt-generated-code definition and the llm-assisted-coding definition.)

In both cases the more experience and mindful experimentation you have the better your results will be.

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

#64

Post by andrewflnr »

ppqqrr wrote: post #32
rafterydj wrote: post #24

Earlier quoted context omitted.

But who _wants_ a program to be alive? To be super clear, I love the tech behind LLMs and other transformers. But when discussing regular, run of the mill software projects that don't require AI capabilities - do you really need to have the understanding of the transcendental nature of LLMs to do that job well?

users.

Users want programs to be predictable. Especially non-technical users.

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

#66

Post by jpollock »

I've just spent the better part of two weeks trying to convince a LLM to automate some programming for me.

We use feature flags. However, cleaning them up is something rarely done. It typically takes me ~3minutes to clean one up.

To clean up the flag:

1) delete the test where the flag is off

2) delete all the code setting the flag to on

3) anything getting the value of the flag is set to true

4) resolve all "true" expressions, cleaning up if's and now constant parameters.

5) prep a pull request and send it for review

This is all fully supported by the indexing and refactoring tooling in my IDE.

However, when I prompted the LLM with those steps (and examples), it failed. Over and over again. It would delete tests where the value was true, forget to resolve the expressions, and try to run grep/find across a ginormous codebase.

If this was an intern, I would only have to correct them once. I would correct the LLM, and then it would make a different mistake. It wouldn't follow the instructions, and it would use tools I told it to not use.

It took 5-10 minutes to make the change, and then would require me to spend a couple of minutes fixing things. It was at the point of not saving me any time.

I've got a TONNE of low-hanging fruit that I can't give to an intern, but could easily sick a tool as capable as an intern on. This was not that.

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

#67

Post by dgfitz »

afro88 wrote: post #56
recursive wrote: post #46

Earlier quoted context omitted.

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.

Do you enjoy the work you had to put in for every single PR? I'm not trying to make a "surely there's 1" annoying argument, but a "surely there's 5-10%". For me, that's: - working in legacy parts of the codebase - anything that requires boilerplate that can't be code genned - actually writing the code of unit tests (the fun part is making code testable, and coming up with what to test) - fixing lint issues that can't…

> working in legacy parts of the codebase

This is why most of us get paid what we do, I’m sure you realize that. There is immense value in having engineers on a team/at a company that can do this.

> anything that requires boilerplate that can't be code genned

It is important to understand the boilerplate. It is also important to understand what is boilerplate and what isn’t. After these things are grasped, usually it’s a copypasta.

> actually writing the code of unit tests (the fun part is making code testable, and coming up with what to test)

If you don’t know how to write unit tests you don’t know how to write testable code. If you do know how to write unit tests you understand the value in maintaining them when you make code changes. Passing that off to a statistical next token predictor renders the tests largely useless

> fixing lint issues that can't be auto fixed yet

You should be thankful you didn’t write code in the 80s if this is a real stance. More thankful still that you rarely need to interact with code sans a linter or autocomplete. There are lots of technologies out there where this isn’t possible. Off the top of my head would be yocto recipes.

> removing old feature toggles

I’m not clear what this even means? You mean, doing your job?

> building a temporary test harness

Generate one, I don’t care. You’ll never know if it’s any good unless you go over the whole thing line by line. At which point, you didn’t save time and didn’t “level up” any skills

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

#68

Post by polishdude20 »

jpollock wrote: post #66

I've just spent the better part of two weeks trying to convince a LLM to automate some programming for me. We use feature flags. However, cleaning them up is something rarely done. It typically takes me ~3minutes to clean one up. To clean up the flag: 1) delete the test where the flag is off 2) delete all the code setting the flag to on 3) anything getting the value of the flag is set to true 4) resolve all "true" ex…

Which LLM? How are you prompting it?

I've been using Cursor for the last few months and notice that for tasks like this, it helps to give examples of the code you're looking for, tell it more or less how the feature flags are implemented and also have it spit out a list of files it would modify first.

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

#69

Post by theLiminator »

jpollock wrote: post #66

I've just spent the better part of two weeks trying to convince a LLM to automate some programming for me. We use feature flags. However, cleaning them up is something rarely done. It typically takes me ~3minutes to clean one up. To clean up the flag: 1) delete the test where the flag is off 2) delete all the code setting the flag to on 3) anything getting the value of the flag is set to true 4) resolve all "true" ex…

Might make sense getting it to instead create a CST traversal that deletes feature flags by their id. Then you have a re-usable trustworthy tool that you can incrementally improve/verify.

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

#70

Post by polishdude20 »

JohnMakin wrote: post #44
GuB-42 wrote: 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.

I agree. I'm hired to build stuff and make it work. I get satisfaction from building stuff people want and use. If I can use an LLM to help me focus more on what the user wants in all for it.

I feel good because real humans are using what I've built and they like it.

Post reply on HN