I don't think it matters how code is produced -- it matters what it achieves. Is there evidence that there is something wrong with recent Bun releases?
I think one of the big disconnects here are the competing views about "what it achieves" means on a fundamental level.
There's the "what it achieves" today; software x works as intended as of right now.
And then there's "what it achieves" long term.
Those with significant experience with sprawling, LLM-generated, codebases, often built by those who don't understand the code produced, can attest to things being good today, unworkable tomorrow.
While this isn't true across the board, and my own experience should be considered anecdotal at best, those who consider "what it achieves" to also include long term viability as a success metric, are skeptical of these types of changes.
Personally, success for dependencies isn't just "does it work today" but "can I trust it to work long term."
I don't use Bun. I don't care about Bun. But my opinion is that how code is produced will have some effect on what it achieves, if the goalpost includes more than "it works today."
I'm not a fan of LLM's injecting themselves into PR/commit content. If you use multiple models, basically whichever one is operating git gets all the credit. But, even if you wrote all the code yourself, and just submitted the PR with Claude Code (or whatever) it would attempt to take credit for the changes.
I currently have rules in all of my skill files forbidding models from advertising themselves or taking credit.
The people who trust bad information from LLMs are the same people who trusted bad information from search results and new articles, it just takes them less time to get bad information.
reply