I spent a good part of my career repeating the old Joel Spolsky line to anyone who would listen: never rewrite from scratch. It was gospel. Rewrites take twice as long as planned, the old system keeps moving under your feet, and by the time you catch up the business has lost patience (and quite likely a few engineers). So when I read on the X engineering blog that X rebuilt the x.com web app from scratch with five engineers working with AI coding agents, in under six months, my first reaction was a raised eyebrow. My second was: hang on, I’ve just made the same bet myself.

What X Actually Did

The old web app (internally “rweb”, short for responsive web) has served x.com for most of the last decade. The new one is built on React, Vite, Fastify, GraphQL and TypeScript, and it replaces three separate servers (one for people, one for search crawlers, one for link previews) with a single one. According to X, the agents did much of the implementation: converting pages, writing tests and fixing the issues flagged in review. The engineers made the architecture decisions and reviewed the changes.

The bit I find most interesting though is the rollout. The new app went live for logged-out visitors and the pages search engines crawl first. Signed-in pages were tested on lite.x.com by employees and testers, and signed-in access is now expanding country by country, with the old app retired once that’s done. In X’s own lab test on a throttled “Slow 4G” connection, the first post on a profile showed up in 2.7 seconds, against 23.9 seconds on the old app. Granted, that’s their test, on their numbers, and real phones on real networks will vary. Still, that’s a big gap.

Five engineers. Half a year. A rewrite of one of the most used web apps on the planet. I suspect that 10 years ago a plan like that would have come with a steering committee, a few dozen people and a much longer timeline.

Why This Is Exactly My Mobile App Decision

Here’s the thing: the economics that made “never rewrite” true have changed, and I’ve just had to make that call on Calendrz. A month ago I decided how to build its mobile apps. The sensible, textbook answer (and the one my own earlier notes recommended) was Capacitor: wrap the existing Angular web app in a native shell, reuse most of the code, write it once. The answer I picked instead was two fully native apps, Swift and SwiftUI on iOS, Kotlin and Jetpack Compose on Android, in two new repositories. In other words, write the whole UI twice. On purpose.

The reasoning is written down in the decision document, and one line in it sums it up better than I can now: code generation is cheap and fast, so engineering hours to write the UI twice are no longer the constraint; review time, the app store review cycles and the setup only a human can do are. The thing Capacitor saved me (writing code) is the very thing whose cost collapsed. And the native features I wanted (widgets, Siri and Shortcuts, writing to the device calendar, a share extension) would have needed Swift and Kotlin anyway, with a JavaScript bridge on top. As such, the “cheap” option had become the one with more moving parts.

The Code Is Cheap. The Plan Isn’t.

Now, don’t get me wrong: I didn’t just tell an agent “build me an iPhone app” and go and make a coffee. What X describes (engineers own the architecture and the review, agents do the typing) matches what I’ve found, and the effort simply moves somewhere else. In my case it moved into the plan.

The mobile work is broken into roughly 40 numbered steps across the backend, the iOS app and the Android app. Each step is sized so it fits in one Claude Code session and ends as one pull request I can actually review. Each one lists what it depends on, and between stages there are gates: what must be merged and deployed before the next stage starts. Within one repository the steps run one at a time, so the next prompt always sees the merged code; across the three repositories they run in parallel. The steps that need a human (creating developer accounts, signing keys, clicking through the store consoles) are spelt out as such, because no agent can do those for me.

And then there’s the contract. The backend generates an OpenAPI description of the exact surface the apps use, the build fails if that file and the code drift apart, and the mobile repos fail their build on any change that isn’t additive. Why so strict? Because once an app is in the store, you cannot update it before the backend ships: old versions stay out there for months. So the apps are told to treat an unknown value as something to handle gracefully, never as a crash. Funnily enough, that contract earned its keep before a single app shipped: generating the iOS client from it showed that parts of my own API weren’t described properly, and that turned into its own fix on the backend (written by an agent, reviewed by me, naturally).

This is X’s rollout in a different shape. They moved logged-out traffic first, then employees, then one country at a time. I’ve got gates, a contract and a rule that the backend changes additively. Same idea: the rewrite itself is the cheap part now, so the engineering judgement goes into deciding the order things happen in, and into making sure the old and the new can live side by side while you get there.

So Should You Rewrite?

I’d argue the question has changed. It used to be “can we afford the rewrite?” and the answer was nearly always no. Nowadays the question is “can we afford the rollout?”: do you have a way to run the new thing next to the old one, move traffic over in slices, and pull back when something breaks? If you have that, a small team with agents can rebuild far more than most leaders think. If you don’t, agents will happily write you a beautiful new system that you have no safe way to switch on.

Truth be told, I think this is where software engineering is heading anyway: people write the specs, the plan and the guard rails, and agents write, test and ship the code. X’s five engineers are an early, very public example of it. And it’s also a warning for any organisation that still needs three meetings and a sign-off to approve a design: a team of five with good agents and a clear plan will have shipped by the time the committee has agreed on the agenda.

Bottom line: rewrite from scratch if you must, but spend the time you saved on the code on the plan for switching it on 🙂