Live data from Hacker News

Vibe coding creates a bus factor of zero

mindflash.org

61–70 of 142 posts

Re: Vibe coding creates a bus factor of zero

#61
post #42

Earlier quoted context omitted.

It’s not a misrepresentation, they’re saying the time it would take to write the code has been reduced to two minutes, not the reviewing and everything else (which still takes just as long)

Reviewing the code you didn't write takes much longer than the one you did.

Reviewing code another person wrote also takes longer than code I wrote. Hell reviewing code I wrote six months ago might as well be someone else’s code.

My job right now depending on the week is to either lead large projects dealing with code I don’t write or smaller “full stack” POCs- design, cloud infrastructure (IAC), database, backend code and ETL jobs and rarely front end code. Even before LLMs if I had to look at a project I did it took me time to ramp up.

Re: Vibe coding creates a bus factor of zero

#62
post #2

The article throws out a lot of potential issues with AI generated code, but doesn't stop for a moment to consider if solutions currently exist or might exist to these problems. - Before LLMs, provided that your team did some of their due diligence, you could always expect to have some help when tackling new code-bases. Has the author never worked on legacy code before? - (oh, and it has forgotten everything about th…

Hello, author here. Thanks for your comment. I agree with your first point, maybe AI will close some of those gaps with future advances, but I think a large part of the damage will have been done by then. Regarding the memory of reasoning from LLMs, I think the issue is that even if you can solve it in the future, you already have code for which you've lost the artifacts associated with the original generation. Overa…

How is that any different than any other legacy code where the reason for the decisions being made have long been forgotten?

Re: Vibe coding creates a bus factor of zero

#63

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…

> Having the LLM write a program to make the changes is much more reliable.

I ended up doing this when switching our 50k-LOC codebase to pnpm workspaces, and it was such a good experience. It still took me a day or two of moulding that script to get it to handle the dozens of edge cases, but it would have taken me far longer to split things up by hand.

I still feel like I am under-using the ability of LLMs to spit out custom scripts to handle one-off use-cases.

Re: Vibe coding creates a bus factor of zero

#64
post #58

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).

Is there really a large difference between 0 and 1 when the average tenure of a software developer is 3 years or less at any given company?

Re: Vibe coding creates a bus factor of zero

#65

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…

personal favorite of mine - I want to switch data api but I dont have time to port 2 different services so here's their documentation. BAM. Done.

Re: Vibe coding creates a bus factor of zero

#66
post #58

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).

True, but when the bus factor is 1, it might as well be zero -- soon you end up with employees (or contractors) who legitimately want more compensation realizing their critical nature. I totally sympathize from the employee's perspective, esp if the 1-factor means they cannot take holiday. Really, it is the company's job to control the bus factor (LLM or human) -- it is good for both the employee and company in the long run.

Re: Vibe coding creates a bus factor of zero

#67

Earlier quoted context omitted.

> * 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…

> Having the LLM write a program to make the changes is much more reliable. I ended up doing this when switching our 50k-LOC codebase to pnpm workspaces, and it was such a good experience. It still took me a day or two of moulding that script to get it to handle the dozens of edge cases, but it would have taken me far longer to split things up by hand. I still feel like I am under-using the ability of LLMs to spit ou…

That’s not even a very large code base. My experience is definitely that anything with more than 100K-loc really makes the LLMs struggle.

Re: Vibe coding creates a bus factor of zero

#68
post #58

Earlier quoted context omitted.

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).

Is there really a large difference between 0 and 1 when the average tenure of a software developer is 3 years or less at any given company?

> Is there really a large difference between 0 and 1 when the average tenure of a software developer is 3 years or less at any given company?

Spot on. 1 might as well be zero. Totally unfair to the worker also, who now cannot take time off.

Re: Vibe coding creates a bus factor of zero

#69
post #52

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.

>> The only way I have seen people "solve" this is by putting a bunch of speed bumps in a process

I solve this by sufficient compartmentalization with good inter-component interfaces. Worst case, you excise part of your system and rebuild. Possibly you can take the schema and docs and rebuild with an LLM :-)

I talk about this in my upcoming book on the topic (link above.) Most good systems are rebuilt 3 or 4 times anyway.

Re: Vibe coding creates a bus factor of zero

#70

Earlier quoted context omitted.

Is there really a large difference between 0 and 1 when the average tenure of a software developer is 3 years or less at any given company?

> Is there really a large difference between 0 and 1 when the average tenure of a software developer is 3 years or less at any given company? Spot on. 1 might as well be zero. Totally unfair to the worker also, who now cannot take time off.

When I was an architect for startups between 2016-2020 doing mostly green field development using new to the company AWS technologies, I made damn sure that any knowledge was disseminated so I could both take a vacation without being interrupted and I could “put myself out of a job”.

I considered it a success when I realized a company doesn’t need me anymore and I can move on and talk about what I did at my next interview in STAR format.

Post reply on HN