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

121–130 of 142 posts

Re: Vibe coding creates a bus factor of zero

#121

Post by IanCal »

serf wrote: post #120
ch4s3 wrote: post #67

Earlier quoted context omitted.

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.

there is more to it than that. it's about modularization as well. I run LLMs against a 500k LoC poker engine and they do well because the engine is modularized into many small parts with a focus on good naming schemes and DRY. If it doesn't require a lot of context for an LLM to figure out how to direct effort then the codebase size is irrelevant -- what becomes relevant in those scenarios is module size and the amou…

This has the side benefit of likely being easier to navigate for humans too. The less I need to keep in my head to figure something out the better.

Re: Vibe coding creates a bus factor of zero

#122

Post by polishdude20 »

patcon wrote: post #78
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 like the spirit of these, but there are waaaay more. Like you only mentioned the ones for professional and skilled coders who have another option. What about all the sub-examples for people all the way from "technically unskilled" to "baby-step coders". There's a bunch of things they can now just do and get in front of ppl without us. Going from "thing in my head that I need to pay someone $100/h to try" to "thing…

*"to vibe out"

Re: Vibe coding creates a bus factor of zero

#123

Post by theshrike79 »

johnfn wrote: 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…

I _wish_ I had an AI tool when digging into some legacy codebases in my past.

"Just ask the author of that perl file".

Sure, it was last edited in -97 and the author is the regional manager now, should I just book a meeting or...?

Re: Vibe coding creates a bus factor of zero

#124

Post by d4rkn0d3z »

I find that bus factor 0 code occurs due to lack of paradigmatic structure or adherence, both internal and external. If you have a paradigm, even a not so great paradigm, I will grok your code and start making changes on my first day.

So maybe that is a test, or something to strive for. If you can get a new developer to make a moderate change to your code base on their first day successfully, then your code is fine. If not you have work to do.

To expand a little on this thought, any one developer's experience is probably not significant but if you hire say 10 new devs and 6-8 are making changes on their first day or in the first few days, your code base is likely fine.

I recomend that a new dev should first make the most trivial change possible but see it through all the way to release, to expose them to process. Following that, a moderate change to expose them to paradigm. All on the first day or in the first few days. If only say 3 of 10 new hires can accomplish the above, the problem is in your code base (or hiring practices).

Re: Vibe coding creates a bus factor of zero

#125

Post by theshrike79 »

theyinwhy wrote: post #110
strgcmc wrote: post #108

Earlier quoted context omitted.

As a manager, I am considering to enforce a rule on my team that -- no README in any repo should ever go stale ever again --> it should be near-trivial for every dev to ask Claude Code to read the existing README, read/interpret the code as it practically currently stands, read what's changed in the PR, then update the README as necessary. This does not mean Claude will be perfect or that engineers don't need to chec…

Why have such a rule if at any moment of time the LLM could update the readme ad hoc? Btw, your ingested readmes will affect your LLM's code generation and I made the observation that more often than not it is better to exclude the readmes from the context window.

No LLM will by default touch a README.md

They will when you run /init, but after that they won't look at it unless directed to do so.

Re: Vibe coding creates a bus factor of zero

#126

Post by matt_kantor »

johnfn wrote: post #88
matt_kantor wrote: post #86

Earlier quoted context omitted.

I can't speak for the author, but I would definitely claim that having a bus factor of zero for any remotely-mission-critical piece of software is "fundamentally flawed", no matter the cause. I'd say the same for a bus factor of one in most settings.

I think that's moving goalposts. The original post never talks about vibe-coding mission-critical software - and I wouldn't advocate for that, either. The post says that all vibe coding is fundamentally flawed.

That's fair, and I agree with you that the generalizations in the article's conclusion go too far.

I added the "remotely-mission-critical" qualifier to capture additional nuance. Tolerance for a low bus factor should be inversely correlated with a project's importance. That wasn't explicitly stated in the article, but it seems uncontroversial, and I suspect the author would agree with me.

Re: Vibe coding creates a bus factor of zero

#127

Post by matt_kantor »

johnfn wrote: post #79
AntwaneB wrote: post #12

Earlier quoted context omitted.

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…

> 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. Overall I find there's a lot of talks (especially in the mainstream media) about AI "always learning" when they don't actually learn new anything until a new model is released. But this already exists! At wor…

To make sure I understand your position:

> But there are plenty of instances where I work with code that has a bus factor of 0.

Do you think this is a problem?

As per my other replies, if all of these instances are in completely unimportant projects, then I could see you answering "no" (but I'd be concerned if you're spending a lot of time on unimportant things). If they are important, isn't the fact that knowledge about them has been lost indicative of a flaw in how your team/company operates?

Re: Vibe coding creates a bus factor of zero

#128

Post by TYPE_FASTER »

Yesterday I did spent about 30-60min reverse engineering some existing code.

A co-worker spent the same amount of time having a LLM do the same thing, and produce documentation that now lives in a wiki.

It would have taken me another 30-60min to produce the same documentation.

The difference is that I, as a person/team member, understand it.

If the model is effectively a team member and is included in all the same conversations ("hey, what about...") then I think it could be roughly equivalent.

Re: Vibe coding creates a bus factor of zero

#129

Post by smaudet »

bongodongobob wrote: post #77
smaudet wrote: post #72

Earlier quoted context omitted.

"bam work you literally would have never bothered to do before done in 2 minutes." And I would never want to use a piece of software written by you ever. If you think that writing the code was the hard part, your code was probably always shite.

Yeah well you definitely already do and don't know it so please spare us the pearl clutching.

Care to elaborate?

I'm sure there's a lot of poorly tested code I use, that doesn't mean I want to use it. :)

In fact, I see a lot of broken things in the wild, frequently.

Re: Vibe coding creates a bus factor of zero

#130

Post by dinfinity »

AntwaneB wrote: post #12
johnfn wrote: 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…

The solution is almost trivial and well known:

Document. Whenever a member of the team leaves, you should always make them document what is in their head and not already documented (or even better, make documenting a required part of normal development).

The thing to understand is that every (new) AI chat session is effectively a member entering and leaving your team. So to make that work well you need great onboarding (provide documentation) and great offboarding (require documentation).

Post reply on HN