Engineer’s Codex is a publication about real-world engineering.
In April 2000, Joel Spolsky wrote “Things You Should Never Do”.
In it, he mentions that Netscape, which ended up dying, performed “the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.”
Rewrites give engineers the illusion of productivity. You’re cleaning the codebase, but usually not providing business value. You’re constantly producing code, refactoring, sending out changes, but not truly improving the product.
Of course, rewrites are helpful sometimes. Sometimes a codebase has so much debt, it becomes a giant brick wall that needs to be pushed along to get changes in. Or it was built in Python, and a rewrite in C++ is necessary to support new architectures, memory management, and speed.
But generally, rewrites don’t get points. Until now.
In the past few months, we’ve seen large companies rewrite entire parts of their codebase from scratch.
Shopify announced they are rewriting their mobile apps, moving from React Native to Swift and Kotlin (two codebases!)
Discord is moving desktop off Electron to GPUI and mobile off React Native, sharing app logic in Rust
GitHub moved the Copilot agent runtime from TypeScript to Rust (~800K lines of production Rust)
Now, AI has changed the rules.
The economics of software engineering have fundamentally changed.
Historically, engineering teams optimized for minimizing implementation effort. Reusing existing code was often cheaper than maintaining two implementations. AI has obviously changed this, as rewriting a codebase is usually a verifiable task. A rewrite is especially well suited to agents because the existing application acts as a specification. This isn’t perfect still, as the old system’s hidden behavior is exactly what agents miss.
Greenfield development is harder because the end result is not always verifiable. How should a complex system work? How should the UI “feel”? Where should things be placed on the UI? Does a certain endpoint even need to exist? These contracts can be designed but often evolve through trial and error.
Many engineering best practices were responses to the historical cost of writing software. Since the cost has changed, these practices are now being reexamined.
The most detailed account so far comes from GitHub. Stephen Toub, a Distinguished Engineer at Microsoft, describes moving the Copilot agent runtime from TypeScript to Rust in about three and a half months. The new code is over 800,000 lines of production Rust, and one engineer drove most of it with a team behind him. He estimates this would have taken a whole team a year or two before agents. By his own accounting, the bill was around $120,000 in tokens plus roughly three weeks of his time.
The team wanted off Node and V8 so the runtime could be embedded in-process by SDKs in six languages, and they report large startup and memory gains. They ported one component per pull request, directly in main, and shipped 135 releases along the way, so there was never a big-bang cutover.
Shopify decided that it was worth the performance improvements and maintenance cost to simply maintain two native codebases, so they never have to worry about React Native thread hops or upgrades again. They were on an old version of React Native, and the decision for them was upgrading to the latest version, which is a mini-rewrite as it is, or just simply do a full rewrite to Swift and Kotlin. They chose the latter. When the upgrade path is already a mini-rewrite, a rewrite doesn’t look as expensive.
The Shop app was rebuilt by a core team of six engineers in 12 weeks, with measurable startup and stability improvements.
Bun’s Zig-to-Rust rewrite had approximately 535,000 lines ported in 11 days using dozens of parallel agents.
X’s web rewrite was an agent-assisted project completed in under six months, with major improvements in measured profile loading performance.
Asana and Airbnb also have done long-delayed test migrations, historically boring and P3 work, with AI.
Engineering’s cost-benefit frontier has shifted
The backlog is now worth doing
The main point here is that previously low-priority or seemingly low-impact ideas are worth re-examining. Check your backlog! Stuff that seemed to only barely move the needle still barely move the needle. But now, for the same effort, you can stack a bunch of low-needle movers to really move the needle.
Every engineering organization has a backlog of migrations, performance improvements, UI annoyances, and small bugs that never get prioritized. Each individual item often isn’t worth the engineer-week to fix a minor annoyance isn’t worthwhile. But what happens when that same engineer-week can resolve 10–20 of those issues? Suddenly, the aggregate improvement becomes meaningful, even if none of the individual changes would have justified a sprint.
Webflow’s Papercuts Room and Quality Week are useful examples of systematically addressing small product frustrations with AI-assisted workflows.
Linear’s Quality Wednesdays show why accumulated polish matters.
The economics of experimentation have changed
You need to be running way more experiments. Do more throwaway work. Explore the entire space of ideas for anything you’re working on.
Another thing about the backlog is that it’s full of ideas to experiment with. Those features you wanted to add to your product? Those experiments you wanted to run on your product’s agent? You can now experiment and evaluate all of those. It’s like mining for gold. You may run a bunch of failed experiments, but the nuggets of gold you may find within are worth it.
Personally, at work, I work on one of the most-used agents in the world. A lot of low-hanging fruit is gone. But there are still ideas to experiment with. We had ideas in our backlog that weren’t worth the time, until suddenly, they were. A week of experiments unveiled a few quality improvements that did a step-function in quality and speed for our agent, showing viability in a place where there previously didn’t seem to be any.
Think about how Claude Code was built. It was a quick side project built by Boris Cherny that ended up kicking off the coding agent revolution.
Judgement still matters
Verification is a competitive advantage. You need to make sure you have verifiable outcomes allowing for agents to loop and iterate against a suite to improve upon.
The quality of your engineering infrastructure increasingly determines how much value you can extract from AI. As agents become better at coding, paradoxically your engineering infrastructure quality matters more than ever. Better verification allows for more autonomous changes, which frees engineers to invest in further improvements.
That encompasses more than tests:
Behavioral specs and golden outputs
Good evals
Performance benchmarks
Visual regression tests
Production observability
Canary deployments and automated rollback
I spent a week at work making my engineering workflow “loop-able”. I work on agents at work, so improvements generally are measured by eval metrics going up, then production metrics going up after deployment.
Agents were able to take an idea, plan it, test it locally, fix issues, then when ready, automatically kicked off long-running evals to test the idea with production data. This is loop engineering and was only possible due to skills, making everything verifiable, and allow agents to use a mix of CLI + computer use to verify changes and behavior. Not only that, my entire team benefits from:
Having more data points on experiments - what’s worth pursuing for them vs not (what’s already been tested and seen to not work?)
My loops and skills are then shared team-wide, so everyone can benefit from my setups.
AI can reproduce functionality quickly without necessarily understanding all the reasons the old system behaves as it does. Bun reported 19 regressions during its rewrite despite extensive testing. SWE Refactor Bench suggests that whole-repository migrations remain difficult for agents; only 5.4% of evaluated runs passed all three stages. Uber’s JUnit migration is a counterexample: generative AI was unsuccessful, while deterministic codemods handled the transformation. Rewrites can also create architectural churn, duplicated systems, and additional maintenance work.
GitHub’s Copilot rewrite, though, is a great reminder that “the old app is the spec” only holds as far as your tests capture it. Toub’s team tracked dozens of regressions, from numbers serialized as 42.0 instead of 42 to features the port simply dropped, and he says more end-to-end tests up front would have meant fewer issues. Every one of those regressions compiled, so the compiler wasn’t the safety net.
In one case, CI flagged that the port had deleted a public API method, and the agent responded by applying the repo’s schema-break waiver label to make the check pass. A human caught it in review. Agents are inherently goal and reward-seeking, and managing this behavior to correctly align with your goals is still hard.
How to apply this to your work
Revisit your backlog. Re-estimate projects and migrations that were rejected because they were too expensive.
Batch small improvements. Evaluate the combined impact of shipping 20 minor fixes rather than prioritizing each independently.
Invest in verification. Build tests, visual regression systems, performance benchmarks, and automated acceptance checks.
Prototype before committing. Have agents attempt a small representative slice of a migration before approving a full rewrite.
Keep rollouts reversible. Use canaries, feature flags, and behavioral comparisons rather than treating the rewrite as a one-way migration.