Rewrite (1 blogmarks)

A rewrite is the thing that eventually gets tossed out as a potential solution for a challenging app. It sounds appealing, but if you've been doing this for a while, you know its way more work than it sounds. The conventional wisdom being, "A rewrite is (almost) never a silver bullet solution."

The math and economics of rewrites have been flipped with good LLM models and harnesses.

I wrote this in response to Jessica Kerr's post which asks:

Question for the world: Which fundamentals or deep lessons of 20 years of programming do we not need to pass on to the current generation of coders, who have never worked without AI?

These kinds of rewrites—big and small—are already happening today.

Anecdotally, I know of an app within one of my clients that was quickly and inexpensively translated from a Rails app to a Go app.

For a higher profile example, the Bun project was rewritten from Zig to Rust in 11 days – full writeup here.

I rewrote Bun in Rust using about 50 dynamic workflows in Claude Code run continuously over the course of 11 days.

This was expensive compared to the Rails->Go rewrite I mentioned above. The actual cost in labor and time was significantly cheaper than had the rewrite been taken on manually.

Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing. By hand, I think this would've taken 3 engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features.