The rewrite

In the blast radius I wrote that I would rather have the twenty percent of a package I actually use rewritten in an hour than install the whole thing. I now think that was the small version of a bigger claim: every application is going to be rewritten from the ground up, and it has already started.

The rewrite nobody would fund

For as long as I have done this job, the full rewrite was the classic mistake. Joel Spolsky called it the single worst strategic mistake a software company can make, and for twenty-five years he was right. You spent years of work to end up where you already were, while your competitors kept shipping.

That reasoning was about cost, and the cost is what collapsed.

A year and a half ago, Microsoft announced it was porting the TypeScript compiler to Go, a multi-year effort by the team that knows it best. Last week Theo posted that a Rust port “might actually happen thanks to Opus 5.5”, with early benchmarks already ahead of the Go version, about twice as fast on Zod. A few months ago nobody would have seriously proposed rewriting a compiler that size again, right after the first rewrite.

It is not just compilers. At Rails World last week, DHH showed 37signals turning Hey from a web app into six native applications, kicked off a week before the talk, and moving its backend to Rust with, in his words, “99% less CPU, 95% less memory”. He also pointed at Shopify, which replaced the React Native version of its Shop app with a native one built by a team of about six people.

Straight to the metal

What gets rewritten is not being rewritten into the same thing. For twenty years we spent most of the hardware progress on developer productivity: web apps where native would have been better, Electron, React Native, one codebase for every screen. It was the right trade, because a programmer hour was the expensive part, and the result was software that DHH described as “slow, bulky, fat and lazy”.

When an agent writes the code, that trade flips. The expensive part is no longer the hour, so there is no reason to give up fidelity to save it. DHH’s phrase for the new target was “as damn near straight to the metal as you can get”. For the apps I build, that means native Swift on each platform and Metal 4 wherever the GPU can help, rather than a shared layer that is a bit worse everywhere.

Legacy is a liability

There is another reason the rewrite is coming, and it is less pleasant. Old software is being taken apart right now.

In the three days before I wrote this, frenchbreaches.com logged five new claims of stolen data in France alone: a medical software vendor with 8.6 million patients claimed, a payroll company, an insurance broker, a property inspection tool and a vape shop. That is an ordinary three days. Most of these are not sophisticated attacks. They are old code, old dependencies and old assumptions meeting attackers who now have the same tools I do.

The same models that write my code are very good at finding the holes in someone else’s. I think it will soon be considered negligent, maybe even criminal, to put code that handles people’s data in production without an AI having written or at least reviewed it. And for a lot of legacy software, having an agent rewrite it will be cheaper and safer than auditing a decade of code nobody on the current team wrote.

Who gets eaten

If rewriting is cheap, the incumbents’ moat gets thinner. I am bearish on the large software houses, the Adobes and Autodesks of the world. Not because their products are bad, but because they cannot move like a young team with very strong opinions about what their software should be.

Every niche is going to get its own dedicated tool: faster, built on current technology, released every week, and made by people who use it. The incumbents still have the file formats, the habits and the training courses, and that buys them a good run, maybe another decade. But I think the direction is down, and the CAD tool I mentioned in the last post is my own small bet on it.

Who does the rewriting

If every application is going to be rewritten, the question that is left is who rewrites it. I would rather it be people who care about the software and have an idea of how it should work, than the default output of whoever got there first. That is the opportunity, and it is open to anyone who has been annoyed by a tool long enough to know exactly what they would change.