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

101–110 of 142 posts

Re: Vibe coding creates a bus factor of zero

#101

Post by bamboozled »

AlienRobot wrote: post #41
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…

Scaffolding is another area where LLM's work great. I want to create a new project using framework XYZ. I already know how to do it, but I don't remember how to set up it since I only do that once, or I don't know how to set up a class that inherits from the framework because I usually just copy the other from another class in the same project. I can simply tell the bot to write the starting code and take it from the…

As long as the LLM is up to date, or you really know the framework / tech well or you will be in a fair amount of pain with little understanding of how to reconcile what it’s got wrong.

Re: Vibe coding creates a bus factor of zero

#102

Post by ehnto »

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…

> work you literally would have never bothered to do before done in 2 minutes.

That has been a nice outcome I didn't expect. Some of the trivial "nice to haves" I can get done by Claude, stuff I just don't have time for.

To your other points I agree as well, I think what's important isn't so much stuffing the context with data, but providing the context with the key insights to the problem you have in your head.

In your first example, perhaps the insight is knowing that you have a special snowflake data structure that needs to be explained first. Or another example is properly explaining historical context of a complex bug. Just saying "hey here's all the code please fix this error" yields less good results, if the problem space is particularly complex.

Re: Vibe coding creates a bus factor of zero

#103

Post by kmoser »

bigiain wrote: post #15
juancn wrote: post #10

I think the article underestimates how much intent can be grasped from code alone. Even without comments. Humans (and I strongly suspect LLMs, since they're statistical synthesis of human production) are fairly predictable. We tend to tackle the same problems the same way. So how something is solved, tells you a lot about why, who and when it was solved. Still, it's a valid point that much of the knowledge is now obs…

> I think the article underestimates how much intent can be grasped from code alone. That's very scale related. I rarely have any trouble reading and understanding Arduino code. But that's got a hard upper limit (at least on the common/original Arduinos) of 32kB of (compiled) code. It's many weeks or months worth of effort, or possibly impossible, for me to read and understand a platform with a hundred or so interdep…

No disrespect for your ability to read Arduino code, but no amount of experience will tell you why the code was written a certain way. Did the programmer not know of any alternatives? Did they specifically choose this one method because it was superior to the alternatives? Did they just run out of time? Is it due to regulatory requirements? The list goes on. To expand further:

FTA:

> but ultimately reading code remains much more complex than writing it no matter what.

I disagree. If reading code is complex, it's because that code was not documented well. If you've written a complex algorithm, that presumably took you hours or days to develop, the proper documentation should allow somebody to understand it (or at least grasp the major points) in a few minutes.

If you're not documenting your code to that level, i.e. to allow future devs to take less time to read and understand than it took you to write--let alone add additional information went into why you made the decisions you did--then you're doing something wrong.

Re: Vibe coding creates a bus factor of zero

#104

Post by jongjong »

The project foundation is everything. LLMs are sensitive to over-engineering. The LLM doesn't have an opinion about good code vs bad code.

If you show it bad code and ask it to add features on top, it will produce more bad code... It might work (kind of) but more likely to be buggy and have security holes. When the context you give to the LLM includes unnecessary complexity, it will assume that you want unnecessary complexity and it will generate more of it for you.

I tried Claude Code with both a bad codebase and a good codebase; the difference is stark. The first thing I notice is that, with the good code base without unnecessary complexity, it generates a lot LESS code for any given feature/prompt. It's really easy to review its output and it's very reliable.

With a bad, overengineered codebase, Claude Code will produce complex code that's hard to review... Even for similar size features. Also it will often get it wrong and the code won't work. Many times it adds code which does literally nothing at all. It says "I changed this so that ..., this should resolve the issue ..." - But then I test and the issue is still there.

Some bad coders may be tempted to keep asking Claude to do more to fix the issue and Claude keeps adding more mess on top. It becomes a giant buggy hack and eventually you have to ask it to rewrite a whole bunch of stuff because it becomes way too complicated and even Claude can't understand its own code... That's how you get to bus factor of 0. Claude will happily keep churning out code even if it doesn't know what it's doing. It will never tell you that your code is unmaintainable and unextendable. Show it the worst codebase in the world and it will adapt itself to become the worst coder in the world.

Re: Vibe coding creates a bus factor of zero

#105

Post by kmoser »

bigiain wrote: post #19
d_watt wrote: post #6

It's potentially the opposite. If you instrument a codebase with documentation and configuration for AI agents to work well in it, then in a year, that agent will be able to do that same work just as well (or better with model progress) at adding new features. This assumes your adding documentation, tests, instructions, and other scaffolding along the way, of course.

I wonder how soon (or if it's already happening) that AI coding tools will behave like early career developers who claim all the existing code written by others is crap and go on to convince management that a ground up rewrite is required. (And now I'm wondering how soon the standard AI-first response to bug reports will be a complete rewrite by AI using the previous prompts plus the new bug report? Are people alread…

As the cost of AI-generated code approaches zero (both in time and money), I see nothing wrong with letting the AI agent spin up a dev environment and take its best shot. If it can prove with rigorous testing that the new code works is at least as reliable as the old code, and is written better, then it's a win/win. If not, delete that agent and move on.

On the other hand, if the agent is just as capable of fixing bugs in legacy code as rewriting it, and humans are no longer in the loop, who cares if it's legacy code?

Re: Vibe coding creates a bus factor of zero

#106

Post by 4mitkumar »

It's fascinating ...didn't think about the Bus Factor at all wrt vibe coding. Feels obvious in retrospect. But I feel there's the other side of software beyond the maintanable, professional-grade software requirements. There are a lot of use cases for basic software to solve that one problem in that one specific way and get it over with. A bit like customized software with little scope and little expectation of long-term support. Vibe-coding excels there.

In a way, I have been thinking about it [1] as the difference between writing a book and a writing a blog post - the production qualities expected in both are wildly different. And that's expected, almost as a feature!

I think as “writing” and distributing new software keeps getting easier - as easy as writing a new blog post - the way we consume software is going to change.

[1]: https://world.hey.com/akumar/software-s-blog-era-2812c56c

Re: Vibe coding creates a bus factor of zero

#107

Post by paulmooreparks »

I find myself acting as a brutal code reviewer more than a collaborator when I lean too heavily on an agent. I literally just typed this into the agent's chat pane (GPT-5, in this case), after finding some less-than-optimal code for examining and importing REST API documentation.

> Testing string prefixes or file extensions is bound to fail at some point on some edge case. I'd like to see more robust discovery of formats than this. This reeks of script-kiddie code, not professional-quality code.

It's true more often than I'd like that the quality of code I see generated is script-kiddie level. If I prompt carefully beforehand or review harshly after, it generally improves, but I have to keep my guard up.

Re: Vibe coding creates a bus factor of zero

#108

Post by strgcmc »

pratikshelar871 wrote: post #56

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

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 check that its summaries make sense (they do, and the human is always accountable for the changes at the end of the day); but this does mean that, the typical amount of laziness that we are all guilty of often, should not be eliminated as a reason as to why READMEs go stale.

Re: Vibe coding creates a bus factor of zero

#109

Post by numpad0 »

aw. I was hallucinating the article content from the title. Bus factor(aka truck factor, lottery factor, honeymoon number, etc.) is number of team members you could lose, hopefully due to positive life events, before the project falls apart. The author argues this could be zero with vibecoded projects, meaning the project could spontaneously explode on full working members.

You want this factor to be +Inf, not 1/+Inf. Just in case it wasn't beyond abundantly clear to all...

Re: Vibe coding creates a bus factor of zero

#110

Post by theyinwhy »

strgcmc wrote: post #108
pratikshelar871 wrote: post #56

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

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.
Post reply on HN