I always wonder what kind of slop people are creating when they say they have a bajillion Claude instances all churning out code.
A guide to Gen AI / LLM vibecoding for expert programmers
31–40 of 122 posts
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#32Earlier quoted context omitted.
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 .
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.
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#33Earlier 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.
Is this a 1-person dev team? Because on teams, one person has to submit a PR and then someone else on the team has to code review it, right? So then you're doubling the review time of the code. If you wrote the code yourself, you would already know that it works, then you submit the PR, and then someone else reviews the code one time, not twice. And typically reading and understanding code you did not write takes longer than writing the code yourself. It does not seem like "AI" coding is really saving anyone any time, and is probably wasting more time than it saves.
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#34generic 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…
> 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.
This part tracks. It's honestly rather generic.
> 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 hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.
This, I'm not sure applies either. TBH the biggest risk I'm seeing already right now is how quickly we're starting to see juniors trying to enter the job market who don't have the faintest idea how actually code. Let alone build software (but let's be honest, that's usually been the case). What decisions to make when writing something are based on factors outside just implementing the functionality: how maintainable is this? how extensible?
Giving a junior a sycophant that's reasonably competent at spitting out something functional (not necessarily functional in the sense you need it to be but apparently working) is a recipe for disaster IMO.
There will absolutely be some who "get it". But, how does that scale?
More worryingly, something I don't see discussed enough is "review fatigue". It's far more fatiguing reviewing the output of an LLM than writing the code yourself a lot of the times. Early on in your career, this might lead to the tendency to just say "eh, looks alright enough".
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#35Earlier quoted context omitted.
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 tech lead I have reviewed code written by junior engineers and written by AI, and there is a very clear difference between the two. You also seem to be missing the point that if vibe coding lets your engineers write 10x the amount of code they previously could in the same working hours, you now have to review 10x that amount. It's easy to see how there is an instant bottleneck here... Or maybe you're saying that…
You have forgotten the most important part: Lay off 90% of those devs.
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#36I always wonder what kind of slop people are creating when they say they have a bajillion Claude instances all churning out code.
Impressive sounding slop that either rarely amounts to anything, breaks, or becomes someone else's problem. Unfortunately I'm starting to see these people at work...
What's worse is they also tend to be the type of "evangelists" that become wildly defensive or accusatory when you question anything about their work.
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#37It'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 literally 10x more productive on personal projects, maybe even 50x.
On personal projects:
- no-one but me needs to decide on requirements
- no-one but me needs to make decisions
- no-one but me needs to maintain the code going forward
- much of the time I'm intentionally using languages and frameworks that I am somewhat clueless about, and an LLM providing continuous ideas (even if sometimes entirely silly ones) stops me getting stuck
- I don't mind if there are large chunks of useless or half-working code
On commercial projects:
- every line of code is a massive liability. Every line needs to be reviewed by another engineer, and every developer who joins the project needs to be aware of it, take it into consideration when making changes elsewhere, and potentially debug it if something goes wrong
- senior engineers are almost always hired to work with languages and technologies they are already very familiar with, meaning for many tasks it's often quicker to write out the code by hand (or perhaps with Cursor's auto-complete) than guide an LLM to do it
- much of the time is spent in meetings trying to unearth the real product requirements or providing updates to stakeholders
- much of the time is spent reading old code and working out how to implement things in extremely large and complex systems in a minimally disruptive way
- a lot of time is spent reviewing other people's PRs, and getting infuriated when people (often either very junior or very senior) produce 1000 line PRs consisting of unnecessary changes, excessive boilerplate, half-finished experiments, and things that clearly haven't been tested properly. This was the case long before LLMs, AI just makes it ever more tempting for people to act this way.
- trying to avoid or gently negotiate political games over who is in control of the project, or who gets to makes technical decisions
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#38This 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.
PRs are as long as they need to be and as short as they need to be. This idea that any problem can be decomposed into 100-200 line changes is ridiculous. That's not realistic in many cases (esp. for refactoring work, etc.)
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#39Trying to get better at vibe coding is like trying to get better at sleeping. The whole point is not to put effort into it.
Not a good analogy. You can put effort into getting better sleep. If the sunlight wakes you up too early, block out the windows. If your bed is uncomfortable, get a more comfortable bed. If the room is too hot, adjust the thermostat before you go to bed. A little bit of effort can go a long way towards getting better sleep.
But you can't change the fundamental operation of an LLM, by its very nature it is not suitable for producing consistently correct results. Getting better at "vibe coding" is an exercise in futility.
Re: A guide to Gen AI / LLM vibecoding for expert programmers
#40Earlier 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?
It depends. I had an LLM whip up a JavaScript function "theThursdayAfterNextSunday"
JavaScript isn't my primary language and date functions are always a pain. But I know enough to review and test the code quickly. It doesn't change a 1-week project into a 4-hour one, but it can change a 20-minute project into a 5-minute one.