All dependency management is speculative. You've got to hedge your bets that the dependency is reliable and fit for purpose. It is reasonable to view Bun's recent choices as increasing the risk associated with depending on it.
All dependency management is speculative. You've got to hedge your bets that the dependency is reliable and fit for purpose. It is reasonable to view Bun's recent choices as increasing the risk associated with depending on it.
Very much agree. Until the vibe-coded version has been fully audited and profiled to perform, within reasonable tolerances, as well as the original code base, it feels like a bad idea to support it downstream or use it in production.
Even if it performs reasonably, it may still be unmaintainable, meaning that any future changes are likely to introduce bugs and instabilities. At the present state of AI coding it’s completely understandable not wanting to depend on code that the maintainers have no good understanding of. The code auditors would have to become the maintainers.
Any rational person investing in AI rewrites at this scale must fundamentally believe that all the downsides of the slop will eventually be cleaned up by the next version of the slop machine. So it's slop all the way down until, wave wands, the slop is indistinguishable from magic.
That is to say, techno jesus cometh.
Yes, but only if auditing includes an exhaustive human review of the code, not just passing the tests we (or an AI) thought to write.
I'd hope that the bun team is going to put into the work to ensure the LLM translated version is up to snuff before cutting a release from it though... it doesn't seem fair to assume that that isn't going to happen.
Really?? So you base your engineer in "speculation". The Bun team has a deep track record of delivering a high quality product. What makes you think that is going to stop?
>What makes you think that is going to stop?
a million-line rewrite over 7-8 days
>What makes you think that is going to stop?
The PR that was merged.