Bun Is Now Mostly AI-Written and the Maintainer Governance Question Is Live

More than 80% of Bun’s commits are now AI-authored. Its creator, Jarred Sumner, put it plainly: “We haven’t been typing code ourselves for many months now.” This is the JavaScript runtime sitting inside an estimated 7.3 million npm installs per month, and the people who write its code have largely stepped back from the keyboard.

That number comes from RedMonk analyst Stephen O’Grady, who published an analysis of Bun in June 2026. The figures here are his reading of public repository data plus Sumner’s own statements, not official Anthropic disclosures. Read with that caveat, the picture is still striking.

The Numbers

Anthropic acquired Oven, the company behind Bun, in December 2025. In roughly 30 months, Bun’s npm downloads grew from about 445,000 per month to 7.3 million. That is close to a 16X increase. Distribution exploded.

The authorship shifted at the same time. By August 2025, more than half of Bun’s commits were bot-authored. After the acquisition, that figure climbed past 80%. Sumner’s quote about not typing code is not marketing. It is a description of how the project now runs.

The third number is the one most people skip. Human contributors to Bun dropped by roughly half. External contributions fell significantly, even though Bun carries an MIT license that legally invites anyone to participate. The license stayed open. The participation did not.

Failure One: Who Governs Correctness

When AI writes the infrastructure and human reviewers thin out, correctness becomes a governance question rather than a coding one.

A runtime is foundational software. Bugs in it propagate to every application that depends on it. The traditional defense was many maintainers reading each other’s work, arguing about edge cases, and catching the subtle errors that compile cleanly but behave wrong under load. That defense weakens when the people doing the reading are fewer and the volume of machine-generated change is higher.

The concern is not that AI writes bad code. It often writes competent code. The concern is the review layer. A pull request generated in seconds still needs a human who understands the security implications, the performance tradeoffs, and the long-term maintenance cost. When that human pool shrinks while output accelerates, the ratio of scrutiny to change collapses. Each line gets less attention precisely when more lines are arriving.

Continuity is the harder version of the same problem. Open source has always depended on people who care enough to keep showing up. If the project’s daily work runs through one vendor’s AI and one vendor’s roadmap, the bus factor stops being about individuals and becomes about a single company’s priorities. Who reviews next year? Who continues if the vendor reprioritizes? These are not hypothetical questions for a dependency that 7.3 million monthly installs rely on.

Failure Two: Concentration Deters Participation

The MIT license says anyone can contribute. The data says fewer people do.

This is the concentration problem, and it is easy to misread as a quality story when it is really a structural one. When a single vendor plus its AI own the development of a project, the signal to outside contributors changes. Why invest evenings reviewing and submitting patches to a codebase where the maintainer has said the code is mostly machine-written and the direction is set inside one company? The incentive to participate erodes even when the legal door stays open.

O’Grady draws a useful contrast with Anthropic’s own Model Context Protocol. MCP took more than ten months to reach a neutral foundation that multiple vendors could trust and build on. That delay was not an accident of paperwork. Vendor concentration slows multi-vendor collaboration because other participants wait to see whether the governance will be genuinely shared before they commit resources. Bun shows the same dynamic from the maintainer side. Single-vendor control, even under a permissive license, suppresses the broad participation that open source depends on.

The result is a project that looks healthier than ever by download metrics and thinner than ever by contributor metrics. Distribution and participation moved in opposite directions.

The Maintainer-Side Mirror

Supply chain risk usually gets framed as injection: a malicious actor sneaks bad code into a dependency you trust. Bun points at a different failure mode on the same surface.

Here the governance does not get attacked. It evaporates. Automation removes the need for many hands, and concentration removes the incentive for outside hands to show up. No villain is required. The combination of AI authorship and single-vendor ownership quietly hollows out the review, continuity, and participation that made the dependency trustworthy in the first place. The license still reads “open.” The governance reality reads “concentrated and automated.”

For anyone running Bun in production, or any AI-maintained dependency, the questions are now operational. How many independent humans review changes to this package? What happens to it if the sponsoring vendor shifts focus? Is the contributor base broad enough to survive a single company’s decision to deprioritize? These are answerable questions, and they belong in your dependency risk assessment alongside the CVE scans.

Do This Now

Audit your critical dependencies for maintainer concentration, not just license type. A permissive license tells you what you are allowed to do. It tells you nothing about who is actually reviewing, governing, and continuing the code. For any dependency where AI authorship is high and human contribution is concentrated in one vendor, document the continuity risk explicitly and decide whether you need a fallback. The download count is a popularity signal, not a safety one. Bun proves the two can move in opposite directions.

This analysis synthesizes What Bun can tell us about AI, open source, and Anthropic (RedMonk, June 2026).

Victorino Group helps teams govern AI-maintained code and dependency risk. Let’s talk.