Can AI Rewrite Bun? The Truth About This Programming Revolution Is More Complicated

The End of an Era? Don't Pack Your Bags Just Yet

A narrative has been making the rounds in tech circles lately: programming as a craft is dying, the days of humans reviewing code are numbered, and Agents will soon take over all coding work. The spark igniting this debate is Bun's rewrite from Zig to Rust — with AI handling a massive share of the code production. Similar signals include EVE Online's migration from Python 2 to Python 3, and Linus Torvalds beginning to seriously use AI-assisted coding.

Taken together, these events can easily trigger a kind of anxiety: are we entering a new world where "whoever has access to the best frontier models and APIs builds better software"? Or is everything business as usual? This article argues the truth is likely a third option — things have genuinely changed, just not in the way you might imagine.

Behind Bun's Rewrite: AI Is Genuinely Impressive — With Prerequisites

The core argument from Paul Dix, CEO of InfluxData and creator of InfluxDB, is that AI wrote roughly one million lines of code and continued refining them over subsequent months. This refers to Bun's publicly released Zig-to-Rust rewrite. According to the video's author, the work made substantial progress in 11 days at a cost of approximately $165,000 in API calls, and Bun now runs on millions of developers' machines.

Some will dismiss this as unimpressive — after all, they had an "Oracle" (the existing version) to compare against, and translating from one language to another is relatively straightforward. But that framing undersells the achievement. It's a compelling example of AI producing genuinely complex software and iterating until it "works."

The key lies in the prerequisites. Bun has not only an excellent test suite, but also a formal specification (essentially code itself) that precisely defines "how things should work." With such a verification system and clear direction, AI can do something truly remarkable.

Bun is a high-performance JavaScript/TypeScript runtime developed by Jarred Sumner, originally written in Zig, designed to replace Node.js with faster startup times and a built-in toolchain. Zig is a systems-level language focused on low-level control and compile-time safety, while Rust is known for memory safety guarantees and a mature ecosystem. Migrating a runtime already running at massive production scale from one systems language to another typically takes years of human effort — the core challenge isn't just syntax translation, but differences in memory models, platform behavior details, and full reproduction of edge cases. Bun's test suite and formal specification were the "foundation" that enabled AI to complete this task: every time AI generated code, tests could immediately verify correctness, forming a tight feedback loop. This "write → verify → fix" cycle is fundamentally the same as TDD (test-driven development) thinking — just with AI as the executor. Without that loop, a million lines of output would just be an untrustworthy pile of noise.

Not a One-Off: Anthropic Built a C Compiler with Opus

Rewriting Bun wasn't Anthropic's first attempt at this kind of task. Previously, it used a set of parallel Claude instances with the Opus model to build a C compiler. Both efforts shared the same critical conditions — a near-perfect "Oracle":

• 30 years of accumulated test cases
• Hard-won code and domain understanding
• The GCC compiler, which the model had effectively "seen" many times during training

In other words, AI was reorganizing and reconstructing existing knowledge under the guidance and constraints of tests, ultimately producing a highly complex C compiler. The commonality between the two cases is strikingly clear: both had extremely powerful build verification systems.

The conclusion follows naturally: if you can provide a formal verification system and clear direction, AI's capabilities are astonishing. But by the same token, that verification system itself is typically the product of years of hard-won knowledge — precisely the kind of thing AI cannot conjure from nothing.

The EVE Online Counter-Example: Why Not Just Let AI Handle It?

The video specifically highlights EVE Online's Python 2 to 3 migration, which began in February 2023. One major challenge: Python 2 and 3 can compile the same code but behave differently. The classic example is division — in Python 2, 1/2 is integer division yielding 0; in Python 3, it's coerced to floating-point yielding 0.5. You can imagine how much chaos that creates.

The author's question is: this kind of work seems perfect for an LLM — "here's 20,000 lines of code, ensure all calculations produce consistent results." Yet EVE chose a slow, incremental approach. The reasons are likely layered: the business risk it operates under is completely different from Bun's, the budget differs, and most importantly — it may be extremely difficult to build a reliable verification system. This isn't the same class of problem.

One nuance worth noting: the EVE team isn't opposed to AI at all — they've been using LLM Agents extensively to work through this 30-year-old codebase: missing documentation, departed original authors, logic nobody understands. So the issue isn't "they don't use AI," but rather that some constraint exists — one we don't yet fully understand — that makes human verification irreplaceable.

The Python 2 to Python 3 migration is widely considered one of the "most painful language version upgrades in history," with an official transition period spanning over a decade (2008–2020). Beyond integer division, the two versions have semantic-level differences in dozens of areas: string handling (bytes vs str), print statements, unicode support, iterator behavior, and more. For a system like EVE Online — running for over 20 years with tens of thousands of players engaged in economic interactions on a single server simultaneously — any subtle change in numerical behavior could trigger in-game economic collapse or security vulnerabilities. The deeper challenge: some of EVE's core logic depends on specific error behaviors in Python 2 (certain edge-case "wrong" outputs have been accepted as "correct" inputs by the game system for a decade). These implicit contracts are nearly impossible to capture with automated testing alone; they require human experts with deep business logic understanding to review section by section.

Linus's Debugging Hell: The Model Said "No Solution," the Human Said "Again"

The most interesting case comes from Linus Torvalds. He recently fought a "hell-level" debugging battle on a graphics driver. During the process, an LLM told him directly: this is an unsolvable bug — just write a report and call it a day.

But Linus didn't stop. He produced 24 debugging patches and 18 kernel boots, ultimately finding the problem — which turned out to be a single line of code.

What makes this story significant: Linus has nearly unlimited model access, and even he couldn't convince the AI that "this is doable." So how far can someone acting purely as an "AI middleman" really get? The author delivers a sharp verdict: if you're just being a proxy for AI, your ceiling is "the worst programmer" — because the worst programmer has access to the same Agents you do.

This case touches on a fundamental limitation of current LLM-assisted programming: reasoning capacity when the search space explodes. LLMs perform brilliantly on problems with clear context and ample training precedents, but when faced with debugging tasks requiring systematic hypothesis elimination and tracking state changes across multiple kernel subsystems, they lack genuine "persistence" — models tend to conclude "unsolvable" when context windows run out or confidence drops, rather than executing 24 ordered experiments to progressively narrow the problem, as Linus did. This difference isn't just about "how much experience" — it's about a kind of metacognition: knowing what you don't yet know, and designing experiments to fill that blind spot. This is precisely one of the core reasons deep professional expertise remains irreplaceable in the AI age.

About That "Everyone Vibe Coding Games with Gemini 3 Flash by Year's End"

The line that opened the video — "by year's end, everyone will be vibe coding video games with Gemini 3 Flash" — was actually ironic. The author already knew the outcome: it didn't happen. Making games is still hard, most demos are low quality, and once you actually try it, you realize — someone who doesn't understand 3D game fundamentals can't conjure a 3D game from thin air. This is a reminder not to let demo video filters distort your sense of reality.

The Real Change: The Dividend from Professional Expertise Has Been Amplified

The author's final position is clear: he now belongs to the camp of "the AI programming era has genuinely arrived." Agents have become very capable, and treating them as stupid is foolish. But simultaneously — the value of professional expertise has increased, not decreased.

His framing is worth remembering: in the past, reading documentation carefully, staying curious, and asking lots of questions might yield a 3% return; in the Agent era, those same habits might yield 10%. The deeper your understanding of code, the better you can guide AI into productive patterns — and the further you can go.

So rather than anxious about "the end of programming," try reframing it: this is a more learner-friendly era. Technical expertise will become a massive differentiating advantage. Don't be the person who just copies and pastes — invest time in getting genuinely good, read the docs, ask questions, stay curious. That's the real moat in the new era.