We sped up bun by 100x

Under the hood, bun's calling these operations when doing a `bun install` and these are the places where integrating 100% gives the most boost. When more and more git deps are included in a project, these gains pile up.

However, the results appear more at 1x parity when accounting for network times (ie round trip to GitHub)

Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement. However, if the original package is in its training data, it's very likely to plagiarize the original source.

Also, who actually wants to use or maintain a large project that no one understands and that doesn't have a documented history of thoughtful architectural decisions and the context behind them? No matter how tightly you structure AI work, probabilistic LLM logorrhea cannot reliably adopt or make high-level decisions/principles, apply them, or update them as new data arrives. If you think otherwise, you're believing an illusion - truly.

A large software project's source code and documentation are the empirical ground-truth encoding of a ton of decisions made by many individuals and teams -- decisions that need to be remembered, understood, and reconsidered in light of new information. AI has no ability to consider these types of decisions and their accompanying context, whether they are past, present, or future -- and is not really able to coherently communicate them in a way that can be trusted to be accurate.

That's why I can't and won't trust fully AI-written software beyond small one-off-type tools until AI gains two fundamentally new capabilities:

(1) logical reasoning that can weigh tradeoffs and make accountable decisions in terms of ground-truth principles accurately applied to present circumstances, and

(2) ability to update those ground-truth principles coherently and accurately based on new, experiential information -- this is real "learning"

Your comment does not seem to be in good faith, implying that they've made up the performance difference. There's a comment with a benchmark here: https://github.com/oven-sh/bun/blob/4760d78b325b62ee62d6e47b...

referencing the commit where they removed the ability to link with libgit2 because it was slower.

Having built a service on top of libgit2, I can say that there are plenty of tricky aspects to using the library and I'm not at all surprised that bun found that they had to shell out to the CLI - most people who start building on libgit2 end up doing so.

I don't know what the bun team actually did or have details - but it seems completely plausible to me that they found the CLI faster for creating repositories.

This was the "validation" used for determining how much progress was made at a given point in time. Re training data concerns, this was done and shipped to be open source (under GPLv2) so there's no abuse of open source work here imo

Re the tradeoffs you highlight - these are absolutely true and fair. I don't expect or want anyone to just use ziggit because it's new. The places where there performance gains (ie internally with `bun install` or as a better WASM binary alternative) are places that I do have interest or use in myself

_However_, if I could interest you in one thing. ziggit when compiled into a release build on my arm-based Mac, showed 4-10x faster performance than git's CLI for the core workflows I use in my git development