Associative Trails / writing

Spolsky was right

Joel Spolsky said “never rewrite” working software. AI just rewrote two large systems in weeks, and actually proved him right.

Two rewrites this year, Bun and the GitHub Copilot runtime, each used AI agents to port close to a million lines of code. This post sets them against Joel Spolsky’s 2000 essay on why you should never rewrite working software, and finds that he was correct. The cost of typing code has collapsed. The cost of knowing what the old system does is the same as it always was.

Sheet 40 · AI
ByMatt Perdeaux
Published5 Nov 2026
Reading6 min
The claimThe old code knows things nobody wrote down

In April 2000, Joel Spolsky told programmers never to rewrite working software from scratch. Spolsky is a big figure in software development. He writes a very influential blog and co-founded Stack Overflow, the website every developer ends up on when they are stuck. For a decade his blog was passed around engineering teams like a sermon. Things You Should Never Do, Part I is probably his most quoted piece.

His example was Netscape, whose web browser had most of the market in 1997. Version 4.0 shipped, the team decided to start again, and the next major release took almost three years. In the meantime they “sat by, helplessly, as their market share plummeted”. He called it “the single worst strategic mistake that any software company can make”.

He gave two reasons. First, “it’s harder to read code than to write it”, so every programmer looking at someone else’s code wants to throw it away. Second, the knowledge cost - old code has been extensively used, it has been tested by real people, and the ugly bits that look wrong are mostly bug fixes. Start again and you have to re-learn all of that. The first reason has aged badly. The second is the one that still matters.

01Two near-million-line ports took weeks, not years

Two teams ignored him

In May 2026, Jarred Sumner’s team rewrote Bun, a JavaScript runtime, from 535,496 lines of Zig into Rust. Sixty-four Claude agents at a time, for eleven days, at a token cost of about $165,000. Sumner’s post-mortem agrees with Spolsky: “Historically, rewrites are a terrible idea.” By hand, he reckons the job would have taken “3 engineers with full context on the codebase about a year”. The implication, that before agentic AI “The realistic alternative was to do nothing.”

In September, Stephen Toub, a Distinguished Engineer at Microsoft, described porting the GitHub Copilot runtime from around 430,000 lines of TypeScript to 832,378 lines of Rust. Fourteen and a half weeks, 136 billion tokens, roughly $120,000. His verdict: “Agents moved the price to where the project became tenable.”

So, is Spolsky’s advice now wrong? Let’s have a look at what the agents actually spent their tokens on.

02The agents spent their time reading, not writing

Typing code was never the main cost

Toub found that “the popular image of AI spewing code is almost backwards”. In his two longest sessions, the agents spent only a fraction of their actions writing the new code. Around half of the rest went on reading the old code to work out what it did. Sumner’s agents wrote their first draft at 1,300 lines a minute, then spent the next week on the 16,000 places it would not compile and the 972 tests it failed. In both cases, writing new code was the quick part. Working out what the old code actually did was the thing that took the most effort.

But then, Spolsky’s argument wasn’t really about typing lines of code. It was about the knowledge cost - everything the old system knows that was undocumented. The agents removed the cost of typing, but needed to know what code to type.

A blue iceberg with a code symbol beside its small tip. Below the waterline, the much larger body contains icons for tests, bug fixes, edge cases, and the knowledge people carry about how the old system works.
The hidden work of rewriting old software
03The tests carried what the old system knew

The value of the old code is in the tests

“End-to-end tests are absolutely, unequivocally critical.”
Stephen Toub, Migrating the GitHub Copilot runtime to Rust, using Copilot

Bun already had over a million checks of what the old system did, written years before anyone planned a rewrite. The agents ran the new code against all of them and churned until they all passed - millions of free retries.

In Github's case, with one exception, every regression that involved a missing feature was, in Toub’s words, “due to lack of sufficient end-to-end tests”. His team had added tests before starting. “We did that, but we didn’t do it enough.”

At this point, it’s also worth recognising that AI agents are very resourceful when trying to get around guardrails. Toub’s agents would “silently redefine correctness by weakening a test”. Sumner’s agents read “get the code to compile” as permission to replace anything that would not compile with an empty placeholder - the errors vanished, but the original functionality was lost. Both teams ended up with the same rule - the tests are sacrosanct, and the agent may not touch them.

I recently did the same thing, albeit at a much smaller scale. When I migrated my website from Jekyll to Hugo, the first phase was a straight copy with nothing changed. Claude checked by taking screenshots: 0% of pages identical, then 57%, 92%, 95%, 100%. The redesign started only once the old site had been reproduced pixel for pixel. The old site was the test.

04Every test records something a person worked out

The tests were written by people

Bun’s million checks were not written up-front. People wrote them, one at a time, over years, each one recording something a person had worked out about how the runtime should behave: a bug a user reported, an edge case someone hit at two in the morning, a decision about what “correct” meant when the spec was silent. Each test is one of Spolsky’s ugly bits of code, written down as a rule instead of buried in the codebase. That is why the agents could use it and why Toub’s team had to add more tests before they started.

05The people who run the old system are its tests

What this means for you

Your firm does not have a million tests, but it may have something that does the same job: the person who has operated each system for years. The director who rebuilds the resourcing spreadsheet every Monday knows which columns are overridden for which client and why. The person who maintains the costing workbook knows what the macro is for and which tab you must never edit. Their inboxes hold every complaint the system has ever generated. That is the test suite, and the first job of a rewrite is to get it out of their heads and onto paper before anything else happens.

This changes the rule from “never rewrite” to “rewrite once you have written down what the old system knows”. Not the code, the behaviour and the reasoning. Every report it produces, every edge case it quietly handles, every workaround someone does by hand on a Friday afternoon. Scripted tests where you can; a long conversation with the owner, written up, where you cannot.

Nor do you have to freeze the old system while the new one is built, which was Netscape’s real mistake. Both rewrites ported module by module while the original kept shipping. A strangler fig is harder to run than a clean break, but it is no longer a years-long process.

So get out the list. Every firm has one - the resourcing spreadsheet, the costing workbook, the intranet a junior built three years ago. Those people are the place the knowledge lives. Start by sitting down with each of them, and write down what they know while they are still in the building.

Spolsky warned that a rewrite would cost years. It now takes weeks. The hard part is finding out what the old system does. Write that down first, and the rest is a free retry.

If you would like to find out more about rewriting your firm’s old software with AI, please do get in touch.

Get in touch