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

11–20 of 122 posts

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

#11

Post by EagnaIonat »

iLoveOncall wrote: post #2

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.

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

#12

Post by mccoyb »

Try and use it for shit and play around with it — you’ll figure out where it sucks, where it is good by yourself.

Play with it — that’s the only way anyone masters anything.

Separate yourself from the results, be prepared to waste time, but try and have some fun and keep your eyes open.

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

#13

Post by ebiester »

iLoveOncall wrote: post #2

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…

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.

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

#14

Post by ajaioslaja »

abletonlive wrote: post #8
iLoveOncall wrote: post #2

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…

You sound like a cynical junior engineer. As a tech lead I have to review thousands of lines of code from human engineers and let me tell you it’s no different than reviewing llm code

As a senior engineer, I can say I probably wouldn’t like working with you.

For a dev worth paying for, the crucial details of some code is discussed prior to the PR in a way that the PR review becomes an afterthought. You can follow this process with an LLM but the PR review is still brutal. It doesn’t do what you say and it doesn’t learn (in a deterministic way a good human dev does).

High performing teams do not have many changes nor comments in a PR (on average, obviously).

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

#15

Post by [deleted] »

ppqqrr wrote: post #7

generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written. if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not…

[deleted]

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

#16

Post by exitb »

ivape wrote: post #6
iLoveOncall wrote: post #2

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…

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?

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

#17

Post by rychco »

iLoveOncall wrote: post #2

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…

> as if just because they have more experience THEY CAN

I don't follow. Why wouldn't you believe that a senior engineer, that has been reviewing code for years, be any better at reviewing code?

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

#18

Post by iLoveOncall »

ebiester wrote: post #13
iLoveOncall wrote: post #2

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…

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.

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

#19

Post by Retr0id »

rafterydj wrote: post #10
ppqqrr wrote: post #7

generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written. if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not…

Not to be rude, but what about understanding the "transcendental nature" of LLMs allows people to build more, faster, or with better maintainability than a "hardened industry titan"?

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.

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

#20

Post by ppqqrr »

rafterydj wrote: post #10
ppqqrr wrote: post #7

generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written. if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not…

Not to be rude, but what about understanding the "transcendental nature" of LLMs allows people to build more, faster, or with better maintainability than a "hardened industry titan"?

we’ve been taught to think of programs as sculptures, shaped by the creator to a fixed purpose. with LLMs, the greatest advance isn’t in being able to make larger and more detailed sculptures more quickly; it’s that you can make the sculptures alive.
Post reply on HN