AI coding productivity is no longer theoretical
AI coding productivity is the measurable increase in developer output and software quality when engineers pair structured workflows with modern AI coding tools on large, complex codebases, allowing them to complete high-risk, specialized tasks such as language ports or compiler rewrites in a fraction of the traditional time while still preserving review, testing and operational stability. Jarred Sumner’s decision to rewrite Bun, a JavaScript runtime, from Zig to Rust with AI is the clearest signal yet that we are past the era of cute auto-complete demos and into systemic changes to engineering capacity planning. Instead of being a novelty, AI-assisted engineering here becomes the main driver of a project plan: the rewrite was even chosen partly because AI made it possible without freezing the product for a year. If you are still treating AI coding tools as optional editor plugins, you are underestimating their impact on developer efficiency gains.
One engineer, 11 days, 535k lines: what the Bun rewrite really shows
Sumner rewrote Bun’s entire runtime from Zig to Rust in 11 days using Claude Code and a pre-release of Claude Fable 5, covering 535,496 lines of Zig and landing a diff of more than one million lines. He estimates the same JavaScript runtime development effort would have taken three engineers with full context about a year without AI, and would have frozen bug fixes, security patches and new features in the process. That is not a marginal improvement; it is a different category of project. Bun is not a toy project: it bundles JavaScript and TypeScript, includes an npm-compatible package manager, a test runner, and reimplements dozens of Node.js APIs. The rewrite was driven by recurring memory-safety bugs in Zig despite Address Sanitizer, fuzzing, and Windows checks. Rust’s borrow checker and automatic cleanup turn those runtime failures into compile-time errors, and AI made that migration feasible on a live product. The productivity multiplier here is measured in headcount-years saved.
The way the work happened matters. Sumner ran about 50 structured “dynamic workflows” in Claude Code over the 11 days, each focused on a distinct phase of the port, from producing a Zig-to-Rust porting guide and lifetimes reference to translating every .zig file into .rs, fixing compile errors crate by crate, and chasing down failing tests until the suite passed everywhere. At peak, four workflow shards ran in parallel, each with 16 Claude instances in separate git worktrees—around 64 agents at once, generating 6,502 commits with a peak of 695 commits in a single hour. This is AI-assisted engineering, not prompt magic: AI is treated as a scalable team of junior developers and reviewers inside a tight human-controlled loop. In that model, the core skill is not typing code; it is designing workflows and adversarial review systems that turn AI output into reliable production software.
From runtime ports to compilers: AI and infrastructure-level speedups
The Bun story is about rewriting a runtime, but the impact of modern tools is just as visible in build infrastructure. The TypeScript team undertook a full rewrite of the language server and compiler into native Go code to fix growing performance problems, especially for large codebases. “TypeScript 7 brings native code speed, shared memory multithreading, and a number of new optimizations that typically yield speedups between 8x and 12x on full builds,” wrote Microsoft Principal Product Manager Daniel Rosenwasser. Compiling Visual Studio Code’s 2.3 million lines of code dropped from 125 seconds in TypeScript 6 to 10.6 seconds in TypeScript 7, an 11.9x increase. That change does not only help one developer’s workflow; it transforms the responsiveness of editors and language servers, shortening time to open files, search code, and trigger auto-completion.
The TypeScript team chose Go as the implementation language because it provided native performance, shared memory concurrency and broad platform support, even though other options like C# and Rust were available. Their previous compiler was written in TypeScript and executed by the V8 JavaScript engine; for some users, such as developers at Slack, type checks had become so slow that full checks were only run in continuous integration systems. With TypeScript 7, those developers can perform full type checks again locally. This shift shows that optimization efforts are moving into the tools that sit underneath every project. While the sources do not claim AI was used to write the Go compiler, the broader pattern is clear: once teams accept radical changes to their stack for performance, pairing that with AI coding productivity becomes an obvious next step. Infrastructure is no longer a fixed constraint; it is another moving part you can rewrite on accelerated timelines.
Why the Bun rewrite’s engineering model matters more than the headline
The most important lesson from the Bun rewrite is not the 11-day duration; it is how AI was integrated into an engineering process. Sumner started by spending hours with Claude to create a detailed mapping of Zig patterns to Rust equivalents and a lifetimes reference for how memory ownership should translate, then validated the plan on three files before scaling up to the entire codebase. He set up adversarial review, where one Claude instance generated code and two separate instances, given only the diff and told to assume it was broken, tried to find reasons it failed. This mirrors healthy human code review, where reviewers are not invested in getting a change merged. One concrete bug the process caught was a use-after-free in process-spawning where a Box was dropped before an asynchronous callback needed it. AI was not trusted blindly; it was treated as a component in a multi-layer safety system.
The post-rewrite story reinforces that the goal was reliability, not speed for its own sake. Bun v1.4.0, the first version built on the new Rust codebase, is available in canary and shows practical gains: memory that used to leak roughly 3 MB per Bun.build() call now levels off around 600 MB regardless of the number of builds, binary size is down about 20 percent on Linux and Windows, and HTTP throughput benchmarks show around 3–5 percent improvements across several server frameworks. Claude Code has been running on the Rust port since mid-June, with a reported 10 percent drop in startup time on Linux. After the port, the team ran 11 rounds of security review and added continuous fuzzing for every parser in Bun, using Claude again to write fix pull requests that humans then review. AI-assisted engineering here is a feedback loop, not a single shot project.
What this means for your timelines and team capacity
When one engineer can, with AI, complete a year-long runtime rewrite in 11 days, developer efficiency gains stop being a local optimization and start rewriting planning assumptions. The Bun case shows that with the right structure—dynamic workflows, adversarial review, incremental validation—you can treat AI tools as a flexible pool of implementation and review capacity that scales up and down with project needs. In parallel, the TypeScript compiler rewrite shows that teams are willing to fundamentally change their language and toolchains to achieve order-of-magnitude improvements in build speed, with TypeScript 7 delivering 8x to 12x faster full builds and cutting VS Code’s compilation time to 10.6 seconds from 125.
The conclusion is uncomfortable but necessary: AI-assisted engineering is turning what used to be multi-quarter infrastructure and runtime projects into plausible sprint-scale efforts for teams willing to invest in workflow design and safety nets. It will not make every developer interchangeable, and it does not remove the need for careful language and architecture decisions. But it does change what a small, focused team can commit to without freezing a product or drowning in technical risk. If your roadmap still assumes that porting a runtime or rewriting a compiler is “too big” to consider, the Bun and TypeScript stories suggest that assumption is already out of date. AI coding productivity is not about writing more lines; it is about making previously impossible projects reasonable to ship.
