Bun creator maps core rewrite in Rust with AI coding agents

**Jarred Sumner has put a real number on a question Rust developers have been arguing about for months: can AI agents help port serious systems code without turning the result into a mess?** His experimental Bun branch, `claude/phase-a-port`, is already enormous, with 76 commits and 1,808 files changed, and the visible work centers on a detailed `PORTING.md` guide for moving core components from Zig into Rust with AI coding agents working alongside the source. That makes this more than a curiosity. It is a live demonstration of how far automated code migration can go when the codebase is performance-sensitive, architecture-heavy, and already in production.

Why this branch matters

Bun is not a toy project. It is the all-in-one toolkit for JavaScript and TypeScript apps, shipped as a single executable and built on JavaScriptCore, with Zig under the hood. The project has always sold itself on speed and practicality, and its ambition is easy to measure: Bun says its goal is 100% Node.js compatibility. It first launched in July 2022, hit 20,000 GitHub stars in its first week, and reached its first stable 1.0 release on September 8, 2023. That history matters because Bun’s reputation was built on disciplined performance engineering, not on speculative rewrites.

The timing raises the stakes even more. Anthropic announced on December 2, 2025 that it had acquired Bun, and said Bun would help power Claude Code, Claude Agent SDK, and future AI coding products and tools. Bun said the project would remain open source and MIT-licensed, with the same team continuing to maintain it. Put those facts next to the branch name `claude/phase-a-port`, and it is easy to see why people are reading the move as a statement about where AI-assisted software development is heading.

What the guide is actually showing

The public GitHub compare view tells a more specific story than the speculation does. The visible first commit is `docs: add Phase-A porting guide`, dated May 4, 2026, which frames the work as a documented phase rather than a hidden rewrite. A second visible commit adds `LIFETIMES.tsv` for pointer-field ownership classification, a detail that says a lot about the workflow: this is not just “translate the code and hope.” It is an attempt to classify ownership explicitly, file by file and field by field, before more aggressive migration happens.

That is the key practical insight for Rust developers. AI can help draft the first pass, compare Zig and Rust side by side, and surface places where a pointer-heavy API needs a more careful lifetime story. But the moment a runtime is touching JavaScriptCore, startup behavior, and memory layout, human judgment still decides the shape of the port. The guide looks less like a magic button and more like a scaffold for a very painstaking engineering process.

Where AI helps, and where it does not

The most interesting part of this story is not that AI is involved. It is the way AI seems to be used as an assistant for repetitive, high-volume translation work while the design choices stay firmly in human hands. A systems port can produce a lot of mechanical churn, especially when every pointer field, ownership boundary, and allocation path needs review. A structured guide plus AI agents can reduce the friction of that work, but they do not remove the need to decide which abstractions should survive, which should change, and which should be rewritten from scratch.

That is where the `LIFETIMES.tsv` clue matters. A table that classifies ownership suggests the team is trying to make the hard parts legible before they are automated. In Rust terms, that is exactly the sort of discipline that keeps a port from becoming a pile of `unsafe` patches glued around a broken translation. AI may be able to accelerate the first draft, but it cannot decide whether the draft preserves the runtime’s invariants, performance profile, and maintainability.

Why the Rust community is watching

For Rust developers, the obvious draw is memory safety. Bun is currently written in Zig, a language chosen by many systems programmers for control and speed, but the current experiment asks a different question: what if the same kind of performance-sensitive runtime were reshaped with Rust’s ownership model at the center? The attraction is obvious. The cost is just as obvious. Rewriting a large runtime is expensive, and Bun’s existing optimization work around startup speed and performance is part of its identity.

That tension is why the discussion has spread quickly across Hacker News and developer circles. Bun’s new owner is explicitly betting on AI coding tools, while Zig’s anti-AI stance has become part of the background noise around the branch. The result is a debate that is larger than Bun itself. It is about whether AI can move from autocomplete and small refactors into the kind of language migration work that usually gets reserved for senior engineers, careful review, and long timelines.

What to take from Bun’s approach if you are planning a port

The lesson is not that every Zig or C-like codebase should be rewritten in Rust. The lesson is that a successful port starts with structure, not enthusiasm. Bun’s public breadcrumbs point to a workflow that separates planning from conversion, tracks ownership explicitly, and treats the port as phased work instead of a single heroic rewrite.

A practical reading of the Bun experiment looks like this:

• Build a guide before scaling the rewrite, so the rules are visible before the code changes multiply.
• Classify ownership early, especially around pointer fields and shared state.
• Use AI for translation and repetitive edits, but keep the architectural calls with humans.
• Preserve performance checks at every step, because a port that is safe but slower may still fail its real job.
• Treat the first branch as evidence of feasibility, not as proof that the final rewrite should happen.

That is why this story is resonating beyond Bun. Sumner is not just porting code. He is testing a new kind of systems workflow in public, with AI agents as active participants and Rust as the destination language under discussion. If the experiment holds up, it could become a template for how performance-critical software moves between systems languages without losing the rigor that made it fast in the first place.