In Just 11 Days, Claude Rewrote Millions of Lines of Code, an Epic AI Engineering Feat Sparks Fury

marsbitPublicado a 2026-07-11Actualizado a 2026-07-11

Resumen

In just 11 days, Bun's founder Jarred Sumner used Anthropic's Claude AI models to rewrite its million lines of code from Zig to Rust. This move sparked significant controversy, particularly from Zig's creator, Andrew Kelley, who publicly criticized Sumner's engineering practices and the decision to use AI for such a massive rewrite. Bun, a high-performance JavaScript/TypeScript runtime and rival to Node.js, was originally written in Zig. After Anthropic acquired Bun, the team encountered persistent stability and memory safety bugs in the Zig codebase. These issues, combined with Zig's strict policy against LLM-generated code, led to the decision to rewrite in Rust. The rewrite was executed using Claude AI tools at an estimated API cost of $165,000, dramatically reducing the expected time and financial cost. Andrew Kelley's response was scathing. He blamed the original bugs on poor engineering habits, calling Bun's Zig code a collection of "hacks on top of hacks." He expressed relief that Bun was no longer associated with Zig, fearing it would misrepresent the language and attract low-quality, AI-generated contributions. The tech community is divided; some view Kelley's critique as unprofessional, while others see it as a defense of engineering integrity. A major concern about the AI-driven rewrite is the resulting code quality. The translation from Zig left approximately 27,000 lines of unsafe Rust code, raising fears about long-term maintainability and technical debt. The...

These days, the tech community has been feasting on drama: Zig programming language creator Andrew Kelley is furious.

The reason? Bun, which had fully committed to the Zig language, was rewritten in Rust by its founder, Jarred Sumner.

Andrew Kelley didn't mince words, showing his anger without the usual polite discourse surrounding such a phenomenal tech event. He directly targeted Jarred Sumner's personal engineering habits, management abilities, and the business logic behind this move.

Bun is a high-performance JavaScript/TypeScript runtime, designed to be a faster, modern direct replacement for Node.js. In recent years, it has become a heavyweight contender challenging Node.js's dominance in the frontend world.

Bun's core selling point is speed: whether it's startup time, dependency installation, or test execution, it far outpaces its competitors, partly because it was originally written in Zig.

In December last year, Anthropic announced its acquisition of Bun, planning to use it as infrastructure to power its AI coding tools, Claude Code and the Claude Agent SDK. Jarred Sumner and other Bun team members are now working at Anthropic.

After large-scale application, especially as the underlying layer for Claude Code, the Bun team encountered what they deemed to be intractable stability issues.

Specifically, the Zig version of Bun had a significant number of memory safety bugs — use-after-free, double-free, forgetting to free memory on error paths, etc. In Zig, these issues rely on coding conventions for prevention, whereas in Rust, the borrow checker and Drop mechanism turn them directly into compilation errors.

On another front, the upstream Zig community maintains a zero-tolerance policy towards code generated by large language models (LLMs). Even optimization patches unrelated to AI could not be merged upstream. The Bun team heavily relies on AI-assisted development, and continuing with Zig meant having to maintain their own compiler fork long-term, at a high cost.

Thus, in May of this year, we witnessed a major engineering feat in the tech world: Bun's founder Jarred Sumner announced that they had rewritten Bun's million lines of code in Rust within 11 days. They used Anthropic's then-unreleased Claude Fable 5 (a Mythos-level model) and the dynamic workflow capabilities of Claude Code.

This was an epic large-scale test of Agentic Workflows, later promoted by Anthropic as a benchmark case for Dynamic Workflows, but it also sparked controversy for "betraying the faith."

In a recent blog post, Zig creator Andrew Kelley argued that the root cause of Bun's bugs before the rewrite was Jarred Sumner's poor engineering habits.

First, even before AI became prominent, Jarred was consistently writing poor-quality code. Kelley stated that the Zig team often reviews users' codebases, and Bun's codebase filled them with "extreme fear." It was full of hacky patches stacked on top of more hacks, abused assertions, and in the rush to push new features quickly, they almost never took time to fix bugs or address technical debt.

Then came the million lines of code generated by Claude. Kelley countered: "Bun officially claims that 1 million lines of unvetted Rust (AI-written) code are safe because there are test cases; well, if the test cases were really that comprehensive, why didn't they catch all those pesky bugs in the original Zig-written version?"

Now, Kelley expresses deep disappointment with Jarred's transformation from an open-source developer with "beginner energy" into a "stinky manager."

Kelley bluntly stated that when he learned Bun was abandoning Zig, he wasn't angry about the betrayal but rather relieved. He was afraid that Bun, bearing the Zig name, would create misunderstandings externally and, worse, attract users who only copy-paste AI-generated code. He even sarcastically remarked that he's now enjoying a cup of tea, glad that "this is finally not my problem anymore."

With such direct confrontation, others in the tech community have joined the fray, sharing their views.

First, some did the math: Claude's tokens are often criticized as expensive, but based on data released by Jarred Sumner and Bun, the Rust rewrite of the Bun project is estimated to have consumed $165,000 in API fees. In the tech and engineering world, this price and timeline are frighteningly cheap.

On paper alone, AI compressed development costs to about one-tenth of the original estimate, and the time was reduced from roughly a year to less than two weeks.

Secondly, there's the debate on the collision of open-source community culture with the AI era. After reading Andrew Kelley's blog post, some felt extremely uncomfortable, believing his public attack on a former major user and sponsor (Bun had long funded Zig) showed a lack of professionalism. Some even radically expressed they had "never before so actively wished for a programming language to fail."

However, veteran programmers also voiced support, arguing that in this era driven by capital and AI hype, Andrew is merely defending pure engineering quality, reminiscent of Linus Torvalds's style back in the day.

Of course, everyone is more concerned about whether the project is still usable after such a drastic overhaul.

The biggest point of contention currently is that, since the 1 million lines of code were mechanically translated from Zig by AI, they lack the architectural refactoring a human engineer would provide. The new codebase retains a staggering 27,000 lines of `unsafe` code blocks. Many worry that the cognitive and debugging costs for human developers maintaining, reading, and modifying this massive "AI-generated blob" in the future might ultimately exceed the upfront development costs saved today.

Will this project, which breaks the established rules of software engineering history, become a milestone where AI reshapes programming paradigms, or will it eventually erupt as an unmaintainable volcano of technical debt? Only time will tell.

References:

https://bun.com/blog/bun-in-rust

https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html

This article is from the WeChat public account "Machine Heart" (ID: almosthuman2014), author: Focus on AI.

Criptos en tendencia

Preguntas relacionadas

QWhat is the main reason Bun's founder, Jarred Sumner, decided to rewrite the entire Bun project from Zig to Rust?

AThe main reason was to address persistent stability issues, particularly memory safety bugs (like use-after-free, double-free) that were difficult to eradicate in Zig. Rust's ownership and borrowing model turns these issues into compile-time errors, offering stronger safety guarantees. Additionally, Zig's upstream community had a zero-tolerance policy for LLM-generated code, which conflicted with Bun team's heavy reliance on AI-assisted development, forcing them to maintain their own compiler fork.

QWhat was Zig creator Andrew Kelley's primary criticism regarding the quality of Bun's original Zig codebase?

AAndrew Kelley criticized that the Bun codebase, even before AI was heavily used, was poorly engineered. He described it as being filled with 'hacks on top of hacks,' rampant use of assertions, and a general lack of effort to fix bugs or address technical debt in favor of quickly shipping new features. He attributed the bugs to Jarred Sumner's 'stinky manager' habits and poor engineering practices rather than a flaw in the Zig language itself.

QAccording to the article, how much did the AI-assisted Rust rewrite of Bun cost in API fees, and how long did it take?

AAccording to data released by Jarred Sumner and Bun, the Rust language rewrite of the Bun project was estimated to have consumed approximately $165,000 in API fees. The entire process of rewriting the million lines of code was completed in just 11 days.

QWhat is a major technical concern raised by developers about the new AI-generated Rust code for Bun?

AA major concern is that the AI mechanically translated the code from Zig to Rust without significant architectural refactoring by human engineers. As a result, the new codebase contains a high number of 'unsafe' code blocks—reportedly 27,000 lines. Critics worry that the cognitive load and debugging costs for future human developers maintaining this 'AI-generated artifact' could eventually outweigh the initial development time and cost savings.

QWhat conflicting viewpoints does the article present about the community reaction to Andrew Kelley's public criticism?

AThe article presents two conflicting viewpoints. One side criticizes Andrew Kelley, finding his public attack on a former major user and sponsor (Bun had funded Zig) unprofessional and lacking in grace. Some even expressed a desire for Zig to fail. The other side, including veteran programmers, defends him, viewing his stance as a defense of pure engineering quality and craftsmanship in an era dominated by capital and AI hype, comparing his directness to that of figures like Linus Torvalds.

Lecturas Relacionadas

Amidst Capital's Encirclement, Decentralization is the Sole Defense for Public Blockchains

In a landscape dominated by power and profit motives, the author argues that decentralization is not merely one desirable feature among many in blockchain design—it is the singular, non-negotiable defense against corporate and capital capture. The article adopts a Machiavellian, realist perspective on human institutions, positing that businesses will inevitably attempt to co-opt any valuable network to protect their profits and dominance. While external attacks like 51% forks are often discussed, the greater existential risk is internal capture—the gradual erosion of a protocol’s neutrality by vested interests, as seen historically with platforms like Visa and Google. The piece critiques permissioned chains, highly centralized “permissionless” layer-1s, and layer-2s without sufficient decentralization (e.g., single sequencers) as inherently vulnerable. These compromised systems, promoted by established financial players, are framed as delaying tactics to stifle truly open networks that threaten existing high-fee, inefficient business models. Real-world examples, such as closed enterprise consortiums that exclude competitors, illustrate how such systems cement oligopolies rather than foster innovation. The author concludes that while decentralized protocols like Ethereum are imperfect and costly to operate, they represent the only viable long-term equilibrium. In a market where value naturally flows to the most secure and neutral settlement layer, only maximally decentralized public blockchains can resist being subsumed by capital and powerful incumbents.

Foresight NewsHace 8 min(s)

Amidst Capital's Encirclement, Decentralization is the Sole Defense for Public Blockchains

Foresight NewsHace 8 min(s)

Who Decides the Rules of Bitcoin? BIP-110 Ignites Governance Debate

Bitcoin's governance is once again at the center of a heated debate, this time ignited by BIP-110, the "Reduced Data Temporary Softfork." This proposal aims to curb non-monetary data (like inscriptions and Runes) by introducing seven new consensus-layer restrictions over a year, such as limiting new output scripts to 34 bytes and restoring the OP_RETURN cap to 83 bytes. The controversy stems from BIP-110's fundamental shift: it moves the battle against "spam" from node relay and miner policies to the consensus layer, rendering currently valid transactions invalid. Supporters, arguing that default policy governance has failed (highlighted by Bitcoin Core v30's relaxation of OP_RETURN limits), see this as necessary to protect node resources and Bitcoin's monetary focus. Opponents, led by figures like Michael Saylor and Adam Back, warn it dangerously centralizes governance. Saylor listed 110 reasons against it, criticizing its low 55% miner activation threshold and potential for chain splits. Back emphasized Bitcoin's "permissionless" ethos, arguing no single group should impose value judgments via consensus rules. Further complicating matters, technical critiques suggest BIP-110 may be technically circumventable, and a "BlockSlop" vulnerability in its upgrade path poses a consensus risk. The debate has drawn in diverse stakeholders: miners (with pools like Ocean signaling support and Foundry polling clients), node operators (like Bitcoin Knots), and new players like corporate treasury holder MicroStrategy (Saylor), whose market influence adds a novel dimension. Ultimately, BIP-110 acts as a governance stress test, exposing the unresolved question: who decides Bitcoin's rules? It pits the authority of miners, node operators, developers, and capital holders against each other, with each side claiming to defend Bitcoin's core principles of neutrality and security.

marsbitHace 24 min(s)

Who Decides the Rules of Bitcoin? BIP-110 Ignites Governance Debate

marsbitHace 24 min(s)

Who Decides Bitcoin's Rules? BIP-110 Ignites Governance Debate

Title: Who Decides Bitcoin's Rules? BIP-110 Ignites Governance Debate A new technical proposal, BIP-110 (Reduced Data Temporary Softfork), has sparked a fundamental governance debate within the Bitcoin community. It aims to impose new consensus rules for one year to limit non-financial data (like inscriptions and Runes) on-chain, moving beyond simple node and miner policy filters to invalidate currently valid transactions. Supporters argue that default policies have failed due to workarounds, necessitating consensus-layer changes to protect Bitcoin's core monetary function from data spam. Critics, including Michael Saylor and Adam Back, contend this dangerously centralizes judgment, undermines permissionlessness, and sets a risky governance precedent. They advocate for market-based solutions like fees or Layer 2s instead. The debate exposes deeper tensions: miners are divided on activation; node operators assert their sovereignty; Bitcoin Core developers influence defaults without direct accountability; and large corporate holders like MicroStrategy now wield narrative influence. Technically, BIP-110 may not fully block data and carries a disclosed consensus bug risk. Ultimately, BIP-110 acts as a stress test, forcing the community to confront the unresolved question: who legitimately decides what Bitcoin is and how it evolves, amidst competing claims from miners, nodes, developers, and capital holders.

链捕手Hace 36 min(s)

Who Decides Bitcoin's Rules? BIP-110 Ignites Governance Debate

链捕手Hace 36 min(s)

Zcash's New Node Zakura Goes Live: Privacy Payments Can Reach 50,000 TPS, Aiming to Rival Visa and Mastercard

Zcash, a privacy-focused cryptocurrency, has launched a new full node software called Zakura version 1.0.0. Developed by Zcash co-founder Sean Bowe and Dev Ojha, with private ZEC donations, its goal is to enable Zcash to process over 50,000 transactions per second (TPS)—matching the scale of Visa and Mastercard—while maintaining full transaction privacy and verifiability. This addresses a key bottleneck, as Zcash currently handles only about 1 private transaction per second. Zakura is a fork of the Zcash Foundation's Zebra node. It features chain pruning and snapshots, reducing disk usage and allowing new nodes to sync in under two minutes. It also offers compatibility with the legacy `zcashd` client interface. The scalability challenge stems from the large data size of privacy proofs. Bowe's Tachyon project aims to use recursive proofs to reduce consensus-layer data needs from ~500 MB/s to ~100 MB/s. For wallet scalability, Valar Group is researching Private Information Retrieval (PIR) tech to allow wallets to fetch their data privately. Zakura supports fast block propagation and the upcoming "Ironwood" network upgrade (NU6.3), scheduled for activation around July 28th. Ironwood was created to contain a critical inflation bug discovered in the Orchard shielded pool in May 2024. The fix uses "turnstiles" to trap any counterfeit ZEC created during the vulnerability period within the shielded pool, preventing it from entering circulation and restoring supply integrity.

marsbitHace 51 min(s)

Zcash's New Node Zakura Goes Live: Privacy Payments Can Reach 50,000 TPS, Aiming to Rival Visa and Mastercard

marsbitHace 51 min(s)

Trading

Spot

Artículos destacados

Cómo comprar EPIC

¡Bienvenido a HTX.com! Hemos hecho que comprar Epic Chain (EPIC) sea simple y conveniente. Sigue nuestra guía paso a paso para iniciar tu viaje de criptos.Paso 1: crea tu cuenta HTXUtiliza tu correo electrónico o número de teléfono para registrarte y obtener una cuenta gratuita en HTX. Experimenta un proceso de registro sin complicaciones y desbloquea todas las funciones.Obtener mi cuentaPaso 2: ve a Comprar cripto y elige tu método de pagoTarjeta de crédito/débito: usa tu Visa o Mastercard para comprar Epic Chain (EPIC) al instante.Saldo: utiliza fondos del saldo de tu cuenta HTX para tradear sin problemas.Terceros: hemos agregado métodos de pago populares como Google Pay y Apple Pay para mejorar la comodidad.P2P: tradear directamente con otros usuarios en HTX.Over-the-Counter (OTC): ofrecemos servicios personalizados y tipos de cambio competitivos para los traders.Paso 3: guarda tu Epic Chain (EPIC)Después de comprar tu Epic Chain (EPIC), guárdalo en tu cuenta HTX. Alternativamente, puedes enviarlo a otro lugar mediante transferencia blockchain o utilizarlo para tradear otras criptomonedas.Paso 4: tradear Epic Chain (EPIC)Tradear fácilmente con Epic Chain (EPIC) en HTX's mercado spot. Simplemente accede a tu cuenta, selecciona tu par de trading, ejecuta tus trades y monitorea en tiempo real. Ofrecemos una experiencia fácil de usar tanto para principiantes como para traders experimentados.

222 Vistas totalesPublicado en 2025.03.17Actualizado en 2026.07.21

Cómo comprar EPIC

Discusiones

Bienvenido a la comunidad de HTX. Aquí puedes mantenerte informado sobre los últimos desarrollos de la plataforma y acceder a análisis profesionales del mercado. A continuación se presentan las opiniones de los usuarios sobre el precio de EPIC (EPIC).

活动图片