The End of Programming? The Truth Behind AI-Rewritten Code and What Really Separates Developers

When AI Rewrites 1 Million Lines of Code in 11 Days

A question is sweeping through the developer community: is the programming we know coming to an end? The spark that ignited this debate was Bun's project to rewrite its codebase from Zig to Rust using AI.

Paul Dix, CEO of InfluxData and creator of InfluxDB, made a striking case: AI wrote roughly 1 million lines of code, then continued refining it over the following months. The entire rewrite was completed in 11 days, cost approximately $165,000 in API fees, and produced reliable software that now runs on millions of developers' machines.

The result is genuinely stunning — but PrimeTime wasn't surprised. His take is direct: if you can build a solid validation system and point things in the right direction, AI can handle highly complex, highly precise software and keep polishing it.

The Prerequisite to Success: The Underrated Validation System

Some argue the Bun rewrite wasn't that impressive — after all, porting from one language to another is inherently straightforward when you have a reference implementation. But PrimeTime thinks that argument misses exactly what matters.

What actually made the AI rewrite possible was the hard-won validation foundation underneath it. Bun didn't just have an impressive test suite — it had something close to a formal specification: a document precisely describing how the code was supposed to behave.

This isn't an isolated example. Anthropic previously built a C compiler using a set of parallel Claude instances, and that project also rested on a perfect validation baseline — three decades of GCC tests, carefully considered and hard-won code, and compiler implementations that had been repeatedly folded into training weights. In other words, AI could effectively reconstruct it because directional guidance and test tooling kept continuously redirecting the process.

There's a paradox here that's easy to overlook: the validation system you depend on to make something that reliable is itself the product of years of hard-fought engineering knowledge. AI's capabilities are built on top of human engineering assets — not a replacement for them.

A note on formal specifications and test suites: A formal specification is a document describing a software system's expected behavior using mathematical or strictly logical language. Unlike ordinary comments or design docs, it can be verified directly by tools. A test suite is a collection of automated test cases covering everything from edge conditions to complex integration scenarios. Together, they form a "validation infrastructure" — its value lies in turning the question "is this code correct?" from a subjective judgment into an automatically executable objective check. For an AI rewrite project, this infrastructure plays a role similar to blueprints and quality standards in construction: every time AI generates a piece of code, tests can run immediately against the specification, and any deviation can be automatically corrected. Without this mechanism, AI-generated code — no matter how reasonable it looks — lacks a credible correctness guarantee. This explains why the Bun rewrite succeeded: its value wasn't just "having a reference implementation to translate from," but that the result of every translation step could be immediately and automatically verified.

EVE's Cautious Migration: Why Not Just Do It All at Once

Another case often cited for contrast is the classic MMO EVE Online. What surprises many people is that the game was written in Python — and its migration from Python 2 to Python 3 has been ongoing since February 2023.

One of the trickiest problems in the migration is that the same code can compile under both Python 2 and Python 3 but produce different results. The classic example is division: in Python 2, 1/2 equals 0 (integer division), while in Python 3 the result is 0.5.

It might seem like you could just "make sure all arithmetic behavior is consistent and convert twenty thousand lines in one shot" — but the EVE team chose to slow the process down significantly and advance step by step. This isn't because they avoid AI. In fact, facing a codebase with 30 years of history where large portions are understood by no one and documentation is sparse, they use generative AI agents quite frequently.

The real difference is this: for EVE, building a reliable automated validation system would be enormously difficult — potentially in a different league entirely — so they have no choice but to rely more heavily on manual verification. This reinforces the earlier argument precisely: where there is no reliable validation system, aggressive AI rewrites lose their safety net.

A note on Python 2 to Python 3 migration: This migration was a slow-burning industry-wide pain point lasting over a decade. Python 3 was released in 2008; Python 2 only reached end-of-life in 2020, during which countless large projects stalled because migration costs were simply too high. The core challenge wasn't syntactic differences (the automated tool 2to3 handles those) — it was "semantic silent changes": code that runs under both versions but behaves differently, such as integer division, default string encoding (ASCII vs UTF-8), and dict iteration order. These issues can't be fully caught through static analysis; they require runtime test coverage of every logical path. For a game like EVE with millions of active players — where any live bug can affect the in-game economy and player assets — missing a single semantic change could cost far more than the migration saves, making the risk-reward ratio of a fast bulk migration extremely unfavorable.

Linus's Hard Case: When AI Says "This Bug Is Unsolvable"

The most compelling example comes from Linus Torvalds himself. He's recently started using AI heavily for programming, and just finished debugging a GPU driver that he described, in his own words, as "a debugging process from hell."

What makes it remarkable: the model told him this was actually a bug that "cannot and will not be fixed" and suggested he write a report and move on. Linus didn't listen. He applied 24 debug patches, booted the kernel 18 times, and eventually tracked down the problem — which turned out to be a single line of code.

This story cuts to the core: if even Linus needs his own expert judgment to override an AI's conclusion to give up, then technical expertise hasn't lost its value in the new era — it's become more critical than ever. AI agents are the same tool for everyone, but who is using them will determine wildly different outcomes.

The Real Dividing Line: Expertise, Not Agency

PrimeTime takes issue with a popular term: "human proxy." He believes using that phrase to describe developers is a massive degradation of people and humanity, and somewhat reduces humans to the same level as a large language model.

His warning is sharp: if everything you do is directing AI to handle everything and serving as its mouthpiece, you will be the first one shown the door. These people are the same as those who used to copy-paste from Stack Overflow without ever truly understanding the system — the only difference is that now you have a faster copying machine.

The conclusion is therefore clear: the more you understand code, the better you can guide AI toward good patterns, and the more progress one person can make. Coding agents have become genuinely powerful — that's not in question. But in this new era, technical expertise will become an enormous dividing line.

Reading great documentation, learning how to stay curious, asking lots of questions — these investments no longer pay "a 3% dividend." They pay "closer to a 10% dividend." If anything has changed, it's this: it's more worth it to learn than it has ever been before.

A note on the "human proxy" concept: The term "human proxy" comes from the AI workflow space, originally describing a human role in fully automated pipelines responsible for handling edge cases that AI can't resolve independently. Its core implication is that human participation is reduced to "a backup input source when AI gets stuck" — not a genuine decision-maker or designer. The danger of this work mode is that it doesn't require the operator to understand the system — only to relay problems and confirm outputs. Similar roles have appeared repeatedly throughout history: workers in the Industrial Revolution who moved things but didn't understand machines; programmers in the internet era who assembled Stack Overflow code without understanding architecture. After every major technological leap, these "executors without understanding" have been the first group to be automated away. PrimeTime's judgment follows exactly this pattern: as tools grow more powerful, people who understand systems benefit more, while people who don't understand systems lose their scarcity value faster.

Is This the End, or an Upgrade?

Back to the original question: is this the end of programming as we know it? Looking across these cases, the answer is closer to "it's actually just a little bit different."

AI can work miracles when a perfect validation system exists (Bun, the C compiler); it still requires human leadership when validation is hard (EVE); and it can misjudge and recommend giving up when facing truly difficult problems (Linus's driver). The way software engineering is practiced will certainly change — but the claim that "humans writing code by hand is nearly over" clearly oversimplifies reality.

Programming isn't ending. What's ending is the approach of not understanding systems and just copying and pasting. Whether you can harness frontier models will amplify — not erase — the capability gap between developers.