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

Vibe coding creates a bus factor of zero

mindflash.org

Post reply on HN
Print view View original

51–60 of 142 posts

Re: Vibe coding creates a bus factor of zero

#51

Post by ants_everywhere »

windows2020 wrote: post #38
ants_everywhere wrote: post #33

LLMs make it vastly easier to work on unfamiliar code bases

A team unfamiliar with a code base demoed asking questions to an LLM about it. The answers genuinely excited some. But anyone who had spent a short time in the code base knew the answers were wrong. Oh well.

That is one anecdote, but it doesn't really have any information in it. To debug the process we'd need to know which LLM, the developer's backgrounds, what prompts they used etc.

I've used a variety of LLMs to ask questions about probably dozens of unfamiliar code bases many of which are very complicated technically.

At this point I think LLMs are indispensable to understanding unfamiliar code bases. Nearly always much better than documentation and search engines combined.

Re: Vibe coding creates a bus factor of zero

#52

Post by hobs »

TuringNYC wrote: post #48

The Bus Factor was an issue long before LLM-generated code. Very few companies structure work to allow a pool of >1 individuals to understand/contribute to it. What I found is -- when companies are well structured with multiple smart individuals per area, the output expectation just ends up creeping up until again there is too much to really know. You can only get away from this with really good engineering managemen…

Yes, its very much a goldfish problem, where work needed grows to fill what is possible, not what is advisable or good. The only way I have seen people "solve" this is by putting a bunch of speed bumps in a process, and generally it just makes everyone lazy and deliver stuff at the last second anyway, not use the additional time to make something polished.

Re: Vibe coding creates a bus factor of zero

#53

Post by appease7727 »

LLMs aren't bad for programming in general.

LLMs are bad for bad programmers. LLMs will make a bad programmer worse and make a layperson think they're a prodigy.

Meanwhile, the truly skilled programmers are using LLMs to great success. You can get a huge amount of value and productivity from an LLM if and only if you have the skill to do it yourself in the first place.

LLMs are not a tool that magically makes anyone a good programmer. Expecting that to be the case is exactly why they don't work for you. You must already be a good programmer to use these tools effectively.

I have no idea what this will do to the rising generation of programmers and engineers. Frankly I'm terrified for them.

Re: Vibe coding creates a bus factor of zero

#54

Post by dumbfoundded »

brandall10 wrote: post #31
p1necone wrote: post #16

If you're using llms to shit out large swathes of unreviewed code you're doing it wrong and your project is indeed doomed to become unmaintainable the minute it goes down a wrong path architecturally, or you get a bug with complex causes or whatever. Where llms excel is in situations like: * I have that I want to apply to - bam, half a days work done in 2 minutes. * I want to set up test data and the bones of unit te…

There's also a middle ground, where you have the AI generate PR reviews and then review them manually. So that 2 minutes of code you spat out (really more like 5-10 using CC) takes another hour or three to review, and maybe 5 to 10 more commits before it's merged in. I've done this successfully on multiple projects in the 10-20k LOC, ~100 file area - fully LLM generated w/ tons of my personal feedback - and it works…

It's definitely a middle ground, but PR reviews, are not perfect. So it's easy to miss a lot of things and to have a lot of extra baggage. From reviewing code it's not always easy to tell exactly what's necessary or duplicate. So I agree, this is a middle ground of using LLMs to be more productive. Removing one bad line of code is worth adding a hundred good lines of code.

Re: Vibe coding creates a bus factor of zero

#55

Post by interstice »

> The only thing you can rely on is on your ability to decipher what a highly imperfect system generated, and maybe ask explanations to that same imperfect system about your code its code (oh, and it has forgotten everything about the initial writing process by then).

This just sounds like every other story I hear about working on ossified code bases as it is. At least AI can ingest large amounts of code quickly, even if as of today it can't be trusted to actually decipher it all.

Re: Vibe coding creates a bus factor of zero

#56

Post by pratikshelar871 »

I recently joined a team with a very messy codebase. The devs were long gone, and even the ones maintaining it didn’t really understand large parts of the code. The bus factor was effectively zero.

What surprised me was how useful AI was. It helped me not only understand the code but also infer the probable intent behind it, which made debugging much faster. I started generating documentation directly from the code itself.

For me, this was a big win. Code is the source of truth. Developer documentation and even shared knowledge are often full of bias, selective memory, or the “Chinese whispers” problem where the story shifts every time it’s retold and never documented. Code doesn’t lie, it just needs interpretation. Using AI to cut through the noise and let the code explain itself felt like a net positive.

Re: Vibe coding creates a bus factor of zero

#57

Post by the_af »

appease7727 wrote: post #49
layer8 wrote: post #32

Earlier quoted context omitted.

> If you're using llms to shit out large swathes of unreviewed code you're doing it wrong > bam, x days work done in 2 minutes This is a bit of a misrepresentation, since those two minutes don’t account for the reviewing time needed (nor prorperly, which vastly exceeds that time. Otherwise you end up in the situation of “doing it wrong” described in your first paragraph.

Most of these cases don't require "review". It either works or it doesn't. If you have an LLM transform a big pile of structs, you plug them into your program and it will either compile or it won't. All programmers write countless one-off throwaway scripts. I can't tell you how many times I've written scripts to generate boring boilerplate code. How many hours do you spend reviewing such tools and their output? I'll…

What do you mean "reviewing" throwaway tools and scripts? If you wrote them yourself, presumably you understand what they do?

I've also spent countless hours debugging throwaway scripts I wrote myself and which don't work exactly like I intended when I try them on test data.

Re: Vibe coding creates a bus factor of zero

#58

Post by the_af »

TuringNYC wrote: post #48

The Bus Factor was an issue long before LLM-generated code. Very few companies structure work to allow a pool of >1 individuals to understand/contribute to it. What I found is -- when companies are well structured with multiple smart individuals per area, the output expectation just ends up creeping up until again there is too much to really know. You can only get away from this with really good engineering managemen…

The Bus Factor was indeed an issue before LLMs, and in fact it's a jargon term that has been in use since forever.

What TFA is arguing is that never before we had a trend towards Bus Factor zero. Before, the worst was often 1 (occasionally zero, of course, but now TFA argues we're aiming for zero whether we're aware or not).

Re: Vibe coding creates a bus factor of zero

#60

Post by NewJazz »

merlincorey wrote: post #37
p1necone wrote: post #16

If you're using llms to shit out large swathes of unreviewed code you're doing it wrong and your project is indeed doomed to become unmaintainable the minute it goes down a wrong path architecturally, or you get a bug with complex causes or whatever. Where llms excel is in situations like: * I have that I want to apply to - bam, half a days work done in 2 minutes. * I want to set up test data and the bones of unit te…

> * I want to apply some repetitive change across a large codebase that's just too complicated for a clever regex, bam work you literally would have never bothered to do before done in 2 minutes. You would naively think that, as did I, but I've tested it against several big name models and they are all eventually "lazy", sometimes make unrelated changes, and worse as the context fills up. On a small toy example they…

Yeah was thinking about this recently. A semantic patch is more reliable, but prompting an ai might be easier. So why not prompt the ai to wrote the semantic patch.
Post reply on HN