MilikMilik

One Engineer, 11 Days, and a Million Lines of Code

One Engineer, 11 Days, and a Million Lines of Code
Interest|High-Quality Software

The new baseline for development speed has quietly shifted

AI coding productivity refers to the measurable increase in how fast and how much useful software a developer can produce when they work alongside advanced AI developer tools that write, review, and refactor large codebases at scale, turning projects that once took teams months or years into work that can be completed in days. Jarred Sumner, creator of the Bun JavaScript runtime, has given that idea a concrete, almost uncomfortable proof: he rewrote Bun’s entire runtime from Zig to Rust in 11 days using Claude Code and a pre-release of Claude Fable 5, a task he estimates would have taken three fully ramped engineers about a year to do by hand. That is not a 20% efficiency bump; it is a different order of magnitude of development speed improvement.

What makes this moment important is that it aligns with another dramatic acceleration: TypeScript 7.0’s new Go-based compiler delivers 8–12x faster builds on large projects, with Visual Studio Code’s 2.3 million lines compiling in 10.6 seconds instead of 125 seconds. Both stories point to the same conclusion: our assumptions about how long software "should" take are now outdated.

One Engineer, 11 Days, and a Million Lines of Code

Inside the Bun runtime rewrite: 3 engineer-years in 11 days

Bun began as a one-person port of esbuild’s transpiler from Go to Zig and has grown into a runtime, bundler, test runner, and npm-compatible package manager—a sprawling codebase with 535,496 lines of Zig, excluding comments. That ambition came with a cost: the team faced a stream of memory-safety bugs in sockets, crypto, and TLS, including use-after-free and double-free crashes, because Zig gives manual control without compiler-enforced safety guarantees. The rewrite to Rust was not a vanity project; it was a response to a clear reliability ceiling in the existing language and tooling.

Sumner describes orchestrating roughly 50 "dynamic workflows" running continuously in Claude Code over 11 days, each focused on phases like mapping Zig patterns to Rust, translating 1,448 .zig files, fixing compiler errors, and getting tests to pass across platforms. This was not one magic prompt; it was intensive engineering management over a swarm of AI agents. The numbers are staggering: 6,502 commits in 11 days, peaking at 695 commits in a single hour, and a diff that added just over one million lines of code to the repository. If we take his estimate at face value—three engineers for a year vs. one engineer for 11 days—that is roughly an 80x reduction in human calendar time for the same scope of work.

AI developer tools as force multipliers, not autopilots

The Bun story shows what AI developer tools can do when treated as serious infrastructure instead of autocomplete toys. Sumner’s workflow leaned on structured, supervised loops: Claude instances generated code, while two separate instances, given only the diff and told to assume it was broken, performed "adversarial review" to find bugs before merge. That mirrors an ideal human review process—detached from the implementer’s intent—but at machine speed and scale. This arrangement caught real issues, including a use-after-free where a Box was dropped before an asynchronous callback had finished with it.

There is a clear pattern emerging around AI coding productivity: the more a team invests in workflow design, the more those AI agents look like a massive, parallelizable junior engineering cohort. Sumner ran up to four workflow shards in parallel, with 16 Claude instances each, for around 64 instances running in separate git worktrees at once, and the pre-merge run consumed billions of tokens through the API. Meanwhile, other Anthropic-adjacent engineers report that much of Claude Code’s own codebase is now written by Claude Code itself, deepening the sense that we are moving toward AI-shaped project scopes and team sizes.

TypeScript 7.0 and the compounding effect of faster tooling

If AI multiply how much code an engineer can change in a day, underlying language tooling decides how quickly those changes become feedback. TypeScript 7.0 delivers a decisive win on that front. After a long effort to rewrite the TypeScript language server in Go, the first stable release with the new native compiler brings shared memory multithreading and optimizations that typically yield 8x–12x speedups on full builds. In benchmarks, compiling the 2.3 million-line VS Code codebase dropped from 125 seconds in TypeScript 6 to 10.6 seconds in TypeScript 7, an 11.9x gain.

The impact is not theoretical. Large users who could not run full type-checks locally, such as the team behind Slack’s codebase, can again type-check on developer machines rather than deferring to CI servers. Everyday workflows—opening files, searching code, getting auto-completion to respond—are directly faster because the language server is no longer the bottleneck. When you combine this kind of TypeScript build performance with AI developer tools that can generate and refactor thousands of lines at a time, you get a feedback loop where both writing and validating code accelerate together.

What this means for software projects from here

These changes are already reaching users. Bun v1.4.0, the first version built on the new Rust codebase, is available in canary and brings tangible improvements: memory that previously leaked about 3 MB per Bun.build() call now levels off around 600 MB regardless of how many builds run, binary size is down around 20% on Linux and Windows, and HTTP throughput benchmarks show roughly 3–5% gains across several server frameworks. Claude Code itself has been running on the Rust port since mid-June, with a reported 10% drop in startup time on Linux. On the safety side, the team has run 11 rounds of security review, added continuous fuzzing across every parser, and even feeds fuzzer-found bugs back into Claude to propose fixes for human review.

In the TypeScript world, the Go rewrite marks a similar inflection point even if the old JavaScript-based server must be maintained for years. Builds that used to be long enough for a coffee break are now short enough that context stays in a developer’s head. The lesson from both cases is blunt: development speed improvement is no longer about squeezing a few percent from human process tweaks. When a single engineer can oversee a million-line runtime rewrite in under two weeks, and a mainstream language can deliver 10x faster type-checks, any team planning software projects on the old timelines will find itself outpaced by those who build workflows around AI coding productivity.

Milik earns a commission when you shop through our links, at no extra cost to you. This article was generated with AI from published sources and product data.

You May Also Like

Comments
Say something...
No comments yet. Be the first to share your thoughts!