Bun's Agentic Rust Port Hit 99.8% Test Compatibility. Its Unsafe Blocks Are Still Unverified

Bun creator Jarred Sumner used Claude Code to port roughly one million lines of Zig to Rust in six days, reaching 99.8% test compatibility on Linux x64 glibc. The result lives on an experimental branch, and it raises a specific technical question: what does that compatibility figure actually certify, and what does it leave open.

The Four-Phase Workflow Behind the Port

According to Sumner's public account of the process and the experimental branch on GitHub, the port ran through four distinct phases rather than a single translation pass.

The first phase gave the agent the existing Zig source, roughly 950,000 to one million lines, along with the pre-existing JavaScript behavioral test suite and the C++ FFI headers for JavaScriptCore, the engine Bun embeds. That test suite defined the correctness target for everything that followed.

The second phase ran more than 100 agents in parallel, generating Rust source that mirrored the Zig architecture. The initial output produced more than 16,000 Rust compiler errors: lifetime mismatches, type resolution failures, and ownership conflicts. That volume of errors is consistent with a direct structural translation from a language with manual memory management into one governed by a borrow checker.

The third phase corrected those errors iteratively over the full six days. Each agent read rustc diagnostics from stderr, applied targeted edits, and recompiled. The fourth phase checked the result against the test suite and benchmarked it against the original Zig build, which Sumner described as competitive on performance.

What the Comparable Numbers Actually Show

Most of the figures Sumner has shared are concrete and directly sourced, which makes a narrow, honest comparison possible without inventing anything the source package doesn't contain.

Test compatibility sits at 99.8% on Linux x64 glibc, the primary verification target Sumner named. The initial Rust output produced more than 16,000 compiler errors, all resolved by day six. The Rust branch also carries roughly 14,000 unsafe blocks, a figure with no direct analog on the Zig side: Zig has no unsafe keyword in the same sense, since the language already operates with explicit allocator control and no borrow checker. That count instead reflects the cost of calling into JavaScriptCore's C++ layer and of carrying Zig's global mutable-state patterns into a language that requires explicit annotation wherever those patterns appear.

What the Test Suite Verifies, and Where That Verification Stops

The 14,000 unsafe blocks mark the actual boundary of what this port has proven. Rust's unsafe keyword does not mean broken code. It means the agent has asserted that a block upholds memory and concurrency invariants the borrow checker cannot prove on its own. In this port, those blocks concentrate in two places: the FFI layer connecting Rust to JavaScriptCore's C++ API, and the global mutable state inherited from the original Zig architecture. Both are expected in a system that embeds a C++ engine and was not originally designed around Rust's ownership model.

The existing JavaScript test suite verifies behavioral correctness at the runtime's public interface: that a script produces the expected output, that timers fire on schedule, that modules resolve correctly. It does not verify whether any of the 14,000 unsafe blocks actually uphold the memory invariants they assert. A use-after-free on a rarely exercised FFI path, or a data race in a threading edge case, can pass every behavioral test and still surface later under load or on a different platform.

This is not a problem unique to agentic code. It is the standing challenge of any large unsafe-Rust codebase. It matters here because the 99.8% figure has circulated in community discussion as evidence of the port's soundness, when it is evidence of behavioral compatibility specifically. Sumner has cited memory leaks and crashes in the Zig implementation as the reason for the rewrite. Whether the Rust branch actually resolves those failure modes depends on whether the unsafe blocks are correct, which the test suite alone cannot confirm.

What the Six-Day Timeline Does and Doesn't Settle

The six-day timeline has drawn most of the outside commentary, including references in Hacker News discussion to what some commenters called an "inverse Hofstadter's Law," the idea that a mechanical translation task can complete faster than conventional estimates would predict. That framing holds for the mechanical part of the job. Rewriting function signatures, allocator calls, and type mismatches at scale is exactly the kind of high-volume, locally constrained work where parallel agentic loops can move faster than sequential human development, and a compiler's own error output is a clean, deterministic signal for that kind of loop to converge against.

What the timeline does not settle is maintainability. Bun's codebase already has documented friction with upstream Zig tooling, including a disagreement with the Zig core team significant enough that Bun maintains its own Zig fork. A codebase this size, carrying roughly 14,000 agent-written unsafe blocks produced over six days, raises an open question about whether the engineers maintaining it can reason about the invariants each block assumes, sometimes called cognitive debt in systems software discussions: the gap between what code does and what its maintainers can actually hold in their heads.

The specific model or models behind the port are not officially confirmed beyond Sumner's own reference to Claude Code; community speculation about additional internal tooling remains unverified and is noted here only to describe the current state of public information. The branch itself is real and public. Whether it becomes Bun's production runtime depends on an audit of the unsafe surface that has not yet happened, a question the test suite was never built to answer.