I don't have the time to audit all the code in a JavaScript runtime myself, so I am forced to make assumptions about the quality of the code based on my trust of the authors.
Additionally, even if the code is good today, I am trusting their process will produce good code tomorrow (as migrating to/from bun has a non-trivial cost). A single person approving the code of an LLM is not such a process with today's technology.
I think this is precisely why I don't mind it that much. I can't audit a huge codebase like a JavaScript runtime, whether the code is by a human from scratch or not. I just have to trust it as a black box.
I've seen LLMs produce terrible code indeed, but I have also seen humans produce terrible code. I haven't dug in to JS runtimes specifically but have read plenty of code in openjdk and cpython - there are many points that could be done better, but there's also no point since it's working, and keeping working code unchanged tends to be a smart decision in software engineering.
So of course the last point brings up whether it was a good idea to rewrite bun if it was working. Apparently the bun team thought the difficulty in getting changes in zig upstream meant it is. I don't intend to hold LLM code to a higher bar than human code - notably if the runtime continues to work, that is as good as I can expect from what is otherwise a huge black box of extreme programming (not that agile kind).
The difference is you can evaluate a small bit of the output of a human or a team of humans and expect all their other code to be roughly in the same ballpark of quality.
An LLM can’t be trusted to produce code and make higher level project structure choices of the same quality at all times, because it can’t be trusted at all - trust is for deterministic systems. But still it begs us to trust it. Every prompt that yields good results sets us up to expect good results, so we get lazy - and then the next prompt it spews out garbage.
As long as the odds are good enough (and/or you know the distribution), there is nothing wrong in relying on and profiting from stochastic systems despite not every outcome being positive. What matters is the sum of outcomes, not the individual ones.
It means you need to be able to handle failure, but you should always have a good grip on how to correct if you intend to set things out in the real world which messes up everything always anyways.
Sure, but that’s not how most llm coding is done, because if a human has to carefully supervise the llm then what’s the point - might as well write it yourself.
Add to that, we’re very good at anthropomorphizing, and very bad at supervising systems that are usually right. Makes for a mess.
Oh, and this all relies on the ai providers not changing things up behind the scenes and feeding you a dumber model sometimes.
jhack's perspetive is something that is all too common in tech. The implication that if code is open source the owners and maintainers don't owe consumers anything because "you can always fork or build it yourself"... as if that were ever possible for the average user, or in a digital world where anything you do with a computer depends on endless recursive sub-dependencies.
It's analogous to saying "it's your fault because you didn't read the T&C's", when all the T&C's you've implicitly agreed to already would take more than a human lifetime to read and understand. That is not a reasonable implication or expectation for the vast majority of people, the vast majority of the time; therefore it is logically corrupt, and should not be entertained.
This is ofcourse a fair point of view for 1-few person codebases built for fun, or to solve their own problems, open sourced out of the kindness of their hearts, but when the open source code is built or maintained as part of a job function (receiving a paycheck) &/or to generate profit (either directly or indirectly to influence standards, gain market share, etc) the open-sourcing is more of a means to build trust and becon attention or adoption in the age of relentless enshittification.
Open sourcing should not be an accepted path for profit seeking orgs or individuals to exploit and screw over consumers, as though they are eternal beta testers whose trust and dependence are worthless externalities. It also completely ignores the time and effort consumers must invest themselves to learn your product, workaround any errors, and build it into their workflow. That is arguably worth significantly more than whatever fee they could pay you for your code.
I still really don’t understand what is so entitled about asking for a level of base empathy and care from maintainers.
People now yell at you that their only obligation is whatever is spelled out in the license they attached to the code. I think this is the same place where the logic of Code = Law comes from. People who think that you can encode the legal/judicial system into a set of axioms. This is not how the law works nor is it how it is taught and asserting this is a fundamental misunderstanding of human systems. It is incredibly destructive when people start applying maths as ground rules for human interaction. People do not live in black/white. We live in grey.
I am certainly not old enough to have experienced it, but I would venture a guess that the reason the BSD/MIT licenses originally existed was so that the universities had a CYA clause. I think you can see this erosion from a group of people sharing software in academic and hobbyist circles into weird legal absolutism as software becomes more of a business. For instance, Bill Gates’ famous letter to hobbyists or the PKZIP fiasco.
> I still really don’t understand what is so entitled about asking for a level of base empathy and care from maintainers.
> People now yell at you that their only obligation is whatever is spelled out in the license they attached to the code.
Let’s turn your implied question around: if a person wants to share code without any expectation of care and maintenance, what should they do? Is the entire concept bogus, and the developer should just keep the code to themselves forever? Or put a “DO NOT USE FOR YOUR BILLION DOLLAR COMPANY” in a README? What communication other than the license could reasonably be provided?
I think the person you’re responding to made a pretty good point that open-source is sometimes the passion of an unpaid 1-person “team” and sometimes the product of a VC-funded attempt to buy goodwill. The idea that asking for more from maintainers is entitled is clearly suitable for the former case but not the latter. Now that Bun has been bought out perhaps they are more deserving of scrutiny.
I'm not arguing against a base level of empathy and care for maintainers.
I'm arguing FOR a base level of empathy and care FROM maintainers WHO CHOOSE to build for-profit products in the open, and that empathy for all parties should be the base expectation from a healthy community, rather than the narcissistic view of "nobody owes their communities anything, regardless of context".
The narssisist view leads to the behaviour of Minio, Bambu, etc becoming an accepted norm; to the abuse, exploitation, and deterioration of open source communities by for-profit orgs.
I honestly trust code reviewed by llms multiple rounds more than human reviewed code. Here is the thing. I don't know the human who wrote the code but i am familiar with the model they use, which might already be better than many human.