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

91–100 of 122 posts

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

#91

Post by nphardon »

I think the idea that it's important to know how to code is going to be seriously challenged. I know I feel like the learning process and insight I gain is important, but I wonder if it is, beyond the subjective.

Like I'm sure the grad students working for Euler learned a ton generating logarithmic tables by hand, but it proved to be useless in the end. Could having a solid grasp on memory management/access in C be the same?

I think this is why obsolescence can be hard to predict.

Like if in 30 years all code is run and managed by ai bots, then all this debate about "it's important to know how to code!" will seem really silly.

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

#92

Post by roadside_picnic »

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…

> Which programmer wants that?!

Agreed.

My LLM usage has quickly become a more efficient way to solve problems that basically require copy/pasting from some documentation I have to look up where me doing it myself is more error prone.

I was recently doing a fairly complex set of data transformations and understanding what the data means remained essential. AI tends to fail spectacularly at really understanding the nuances of data (that often requires understanding the underlying business logic generating the data).

However it's very useful when I have to do a bunch of window functions, where I can describe the operation but don't want to look up the syntax. Or just writing SQL when I can explain exactly what I need it to do.

Similarly working with Pytorch involves a fair bit of what I consider pseudo-boilerplate where the code itself is quite boring, but contains just enough complexity that it can't be simply automated away. Hand rolling this stuff often leads to small errors/bugs, but LLMs can do a spectacular job of quickly generating this, provided you do know exactly what you're looking to build.

What's interesting is that this has still been a major speed boost, because looking up how to do some tedious thing you just forgot how to do can really break flow.

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

#93

Post by percentcer »

I like programming. It's fun, and sometimes it even requires creativity. There are plenty of times when it's not that fun, and doesn't require any creativity (because whatever it is has been done by someone else a thousand times over), and you just want a result. Vibecoding is great for _that_ stuff (think little throw-away scripts, shell one liners, tool plugins, etc)

I generally don't get great results from LLM code because most of my work is in C++ (which I'm guessing is underrepresented in the training data?), but when I point it towards some well-worn javascript thing I've had real successes! Most recent example is this little chrome plugin I had it whip up in one shot (https://chromewebstore.google.com/detail/favicon-tab-grouper...) because I couldn't find the exact functionality I needed in other plugins.

Works perfectly for my needs, took less than five minutes to spin up, and I use it all the time. If you're looking to get started with vibecoding stuff, try making plugins that provide niche functionality for your hyper-specific workflows.

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

#94

Post by kiitos »

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.

building stuff is the application of programming, not the platonic form of it

if you see programming as a necessary but ultimately annoying means to an end, that's fine, you do you, but there are many other folks who don't look at it that way, and they're no more or less right or wrong than you are

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

#95

Post by dimtass »

After 25 years in embedded, embedded Linux, devops and cloud security I don’t care about coding anymore. I’ve done almost everything in so many programming languages and assembly that I can’t even count. Every programming task seems like a repetitive task. But architecture and solving a real problem wow, this still kicks in me. So, LLMs are my pals that we spend so much time in planning and go to every single small detail and in such depth that it’s hard to explain the mental erection. Just give it a prompt to try to contradict every step and make it hard for you and try to convince it that it’s wrong. I can spend hours just building the plan and the idea. Then I have the solution and it’s just boring to write the code. I know I can write the code and I’ve already done it before. So, I just create a full plan with specs and a water flow to do list and let it do the job. I check if it does it right and keep it on track not to over engineer things (they tend to do that a lot) and just enjoy the outcome. I would say I do vibe-planning before vibe-coding.

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

#96

Post by iLoveOncall »

polishdude20 wrote: post #75
leptons wrote: post #22

Earlier quoted context omitted.

It takes way more time to explain, and then re-explain, and then re-re-re-explain to the LLM what I want the code to do. No, it isn't because I don't understand LLMs, it's because LLMs don't understand , period. Trying to coax a fancy word predictor to output the correct code can be extremely frustrating especially when I know how to write the code.

Usually if you have to re re re explain, it means you didn't leave those details in the first prompt. So writing out the code yourself, you'd still get into this trap because you discover as you write. Just like you discover the details as the LLM writes.

Do you have access to GPT-10 or something like this? Because my experience is that you can give as much detail as you want and you WILL need to re re re explain regardless.

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

#97

Post by tharkun__ »

channel_t wrote: post #90
starfallg wrote: post #84

Earlier quoted context omitted.

The reality is that hacking code isn't always beautiful. Most of the time, it is mundane grunt work. You can always leave the core logic for your to work on and have the AI handle all the bits that you don't like to do. This is what we do for modelling for example, AI helps with the interface and data backends, the core modelling logic is hand-crafted.

Yup. I think programmers are giving themselves too much credit here. I love programming, but let's not kid ourselves, at most organizations at least 75% of the code needed to make something a working product is BS. I'd rather prompt an LLM agent to take care of that while I review it so that I can spend my limited energy on the more interesting bits. I find the exercise of prompting an LLM to generate boring code to…

Sounds like you really like code reviews. You must be a unicorn.

I find most programmers don't like code reviews. They do it because it's required by their job and most will just click the approve button. Or I guess in a more dysfunctional org, argue about formatting or something, which should just be done automatically so that nobody has to even think about it.

What they like doing is the coding and problem solving.

And now you want to make programming into code review?

How's that gonna go?

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

#98

Post by Ethee »

polotics wrote: post #85

This appears to me to be a surprisingly low-effort article. Nothing about managing context length and starting tasks from a good context, managing .md files and structuring repos, very anthropomorphising which does not help, nothing about tools to use to build the right context, no comparison of different approaches, what kind of MCP and/or RAG to get agents to look at documentation.

The article clearly isn't directed at how expert programmers are 'supposed' to use AI, though we see at least one of those a day on the front page of HN now. The first paragraph makes it pretty obvious that the author is trying to convince people who have completely disregarded AI, for one reason or another, to give it another try in a more meaningful way. Telling the reader how the author configures his AI isn't going to convince those people, as they likely are already very aware of how these tools 'work' the problem is in the 'how to use them' department which has nothing to do with what MCP tool you're using.

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

#99

Post by CuriouslyC »

uncircle wrote: post #29
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…

> I think the article could be more accurately titled "A Guide to Gen AI / LLM Vibecoding for Programmers who hate their job" Given how “vibe coding” is all about explaining clearly the requirements and defining context, it’s for programmers who should have chosen middle management as a career. To actual programmers that enjoy the craft, using an LLM means ruining the beautiful art of abstraction and mental visualisa…

I choose the tech stack and architect the project.

I choose the language patterns and code organization.

I step in to solve hard problems when agents flounder.

What about that says middle management? It's just getting rid of all the low iq parts of the job.

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

#100

Post by ChrisRackauckas »

polotics wrote: post #85

This appears to me to be a surprisingly low-effort article. Nothing about managing context length and starting tasks from a good context, managing .md files and structuring repos, very anthropomorphising which does not help, nothing about tools to use to build the right context, no comparison of different approaches, what kind of MCP and/or RAG to get agents to look at documentation.

That's kind of the whole point. Setting up a few MCPs etc. is really a minor thing in the grand scheme of things. Sure, I have setup context7, Sequential Thinking, etc. and my Claude.md has a lot of details in it, but that only improves the accuracy so much. My whole point is that if the mindset is "I need this to be very accurate for it to work", then you're already putting too much effort into it. I personally have not found any of that time worth it. For any PR I had to put effort into, I could have done it quicker myself. So I learned those things and they just didn't have a payoff for my work. They did really well in some things like front end development, devops, and stuff of that sort, but if it's the normal kind of problem that is my "here's my actual hard problem of the day", i.e. something where I would need to start white boarding a new algorithm and semi-prove some numerical stability result before throwing code, the LLMs just fail to ever come up with anything new enough to get a solution.

But, slamming down commands for it on only easy problems in order to get 90% of a PR done and just finishing it yourself? That can get you 6 PRs in instead of 3, where you did the hard 3 and just looked at the transcripts for another 15, and tossed all but the 3 that looked good. Using Claude like that takes about half an hour out of your day and you get a good benefit, and that is what I am pointing to as a very useful approach.

I personally don't think any amount of MCP servers will make "Claude, find me a novel algorithmic improvement in this space and code it up" work, but hey if that works for you that's great. But reviewing and checking the proofs would likely make it not worth it for what I'm doing.

Post reply on HN