5 guests 5 episodes 3,878 words

Things You Should Never Do, Part II: The Rewrite Question in the Age of AI

Should you ever throw away your codebase and start over, or is a rewrite always a doomed trap?

In 2000, Joel Spolsky called throwing away a working codebase "the single worst strategic mistake that any software company can make." A quarter century later, the answer turns out to depend on which crime scene you are standing in. Tanguy Crusson is standing in the wreckage of HipChat and Stride, the product Atlassian spent three years rewriting while Slack and Microsoft Teams lapped the field. Will Larson is standing next to a table of untouched sushi and champagne flutes, served at the Digg v4 launch party while the production site refused to come back up. Jay Baxter is inside the post-layoff X offices, where a forced audit of Community Notes discovered that deletion, not rebuilding, was the highest-leverage move the team had ever made. And Dhanji Prasanna, CTO at Block, is typing prompts to an AI agent, deleting the output, and calling this the new baseline.

Four rooms, four answers. What sounds like a simple engineering question — rewrite or evolve? — is really a debate about how much of your product's value is trapped in undocumented code, how fast competitors are moving, and whether the cost of rebuilding from scratch is still a universal constant or has just collapsed overnight.

You are staring at an aging system. It is hard to support, nobody wants to work on it, the business is asking for capabilities the architecture cannot gracefully absorb, and a competitor is moving faster. Do you take the engineers who want to go greenfield seriously and authorize a rewrite — or do you treat that impulse as the warning sign of a project that will eat your company? And in an AI-native world, does that calculus still hold?

The 3 Positions

1 / 3

Never Rewrite — Evolve in Pieces or Die

Camille Fournier · Tanguy Crusson · Will Larson

Camille Fournier — Managing Director at Two Sigma, former CTO of Rent the Runway, and author of "The Manager's Path." One of the most widely read engineering management authors in tech; has personally overseen multiple re-architectures at scale.

Fournier's case against rewrites is fundamentally about epistemic humility. The seductive logic — this old thing is crappy, let us just go build the new thing — underestimates two things simultaneously: how much the old system actually does, and how little the team understands about what it does. Engineers pushing for a rewrite have almost never catalogued the undocumented business logic, the edge cases, the hard-won bug fixes. They imagine a clean slate, and then spend the next eighteen months slowly rediscovering, one production incident at a time, all the reasons the old code looked the way it did.

"I have personally overseen a number of, if not quite rewrites, re-architectures and major system evolutions. So I absolutely do think they are sometimes a thing that needs to happen, but I also, have seen so many instances of cases where the engineers have convinced themselves that the only solution to the woes that they're experiencing with the system, it's hard to support, it's hard to change. Nobody wants to work on it, because it's this old crappy technology, is that they just have to go over to the side, build the new thing that will replace this old system and that is going to sort of free them from their misery."
Camille Fournier
▶ 00:14:50

Her most valuable contribution is a diagnostic question that often kills the rewrite impulse before it forms. If the only honest answer is "no," the rewrite is an aesthetic project and you should stop.

"If I could go away and not touch this and not do anything to it for a long period of time without it really harming my business, is it worthwhile to change it at all?"
Camille Fournier
▶ 00:17:47

The deeper technical argument is that the hard part of any rewrite is not the build — it is the migration, and teams systematically price only the build.

"There's so much logic buried in legacy systems, it tends to be undocumented, it tends to be weird. You haven't thought through all the business rules, you haven't thought through the data formatting and I think again, it's much, much harder to replicate all the important things from the old system to the new system than people expect."
Camille Fournier
▶ 00:18:45

Her constructive alternative is surgical: identify a well-contained subsystem, uplift it behind a stable interface, clean up its tech debt, and leave the rest alone.

"My advice would be when you're struggling making an evolution plan, take pieces potentially of the old system, uplift them, make them more scalable, make them easier to work with, clean up the tech debt, but trying to say we're going to just go away. We're going to rewrite, we're going to build something brand new and it's going to solve all our problems, it just very rarely works."
Camille Fournier
▶ 00:19:14

Tanguy Crusson — Head of Jira Product Discovery at Atlassian, previously PM on HipChat and Stride. Spent three-plus years leading the HipChat/Stride rewrite that ended with Atlassian exiting enterprise chat entirely.

Crusson is the hard-earned version of Fournier. He is not arguing from principle; he is arguing from a body at the crime scene. HipChat was Slack before Slack — a beloved, fast-growing product with a cult following. When Slack emerged as an existential threat, Atlassian poured developers, PMs, and designers onto the product under the banner of "HipChat Go Big." But the platform could not absorb that many contributors simultaneously, so the team concluded the only way forward was a rewrite. That decision, Crusson now says flatly, was the original sin.

"The platform is not so ready for so many people to work on it. And so we got to the inevitable, okay, it's too much tech, we can't do much about it so we made the decision to rewrite it. There's lots of literature around there around should you do rewrite? Should you not do rewrite? You ask me now, I tell you never. Trust me."
Tanguy Crusson
▶ 00:16:15

The rewrite became the product rebranded as Stride. By the time it shipped, Slack had pulled miles ahead and Microsoft had bundled Teams into Office for free. Atlassian eventually sold HipChat and Stride to Slack; the stock price went up ten dollars the day the shutdown was announced.

"Never do a rewrite, and there's good reasons for that. But basically we did that and out of it came up actually a new product called Stride, which was initially 'HipChat next gen.' The problem is that the product was great, but by the time we were done, Slack was just miles ahead of us."
Tanguy Crusson
▶ 00:16:46

The structural lesson: a rewrite, a platformization, and a competitive war were each individually hard, but stacking all three at once was impossible — and the rewrite was the one they had the most control over and should have refused.

"We thought that we could tackle the rewrite and we could tackle the platformization. All these things were necessary, but all of them at the same time was probably a bit too much to bite."
Tanguy Crusson
▶ 00:31:55

Will Larson — Engineering executive at Calm, previously at Carta, Stripe, Uber, and Digg; author of "An Elegant Puzzle" and "Staff Engineer." Direct hands-on experience of one of the most famous rewrite failures in startup history.

Larson brings the most viscerally specific rewrite horror story in the archive: Digg v4. What makes it load-bearing is that the strategic thesis was actually reasonable — Digg was losing to emerging social networks, and the existing architecture could not support the social layer the team believed was existentially required. This is the strongest possible case for a rewrite — not engineer aesthetics, but a genuine capability gap tied to a real business thesis. And it still failed catastrophically.

"The decision that was done, I think two and a half years before I joined, and the shift about six months after I joined was they needed to do a complete rewrite in order to get there. This is a decision that never works out for anyone. So I think as someone with more experience, I could have predicted this wasn't going to work out. But I was earlier in my career."
Will Larson
▶ 01:03:39

Larson's launch-day story is one of the most painful images in the archive — the distance between the team's expectations and reality, caught in a single photograph.

"There's one picture that I've kept and there's a picture of a lot of the engineers around this table in the middle of this giant office and they're serving sushi. We had waiters, caterers come in that day. They're serving sushi. They have plates with champagne flutes on it. There was a full bar and we're all around this table because the site is not up."
Will Larson
▶ 01:02:33

What followed is the part of every rewrite story that never makes the pitch deck: team belief collapses fast. Not in quarters, in weeks.

"We wiped pretty much all of our existing servers to re-image them to the new software. We try to bring the site up and just keeps crashing. And so it basically takes us a month to get it fully functional again. And so that day sitting around that table with champagne and sushi, that's just like day one. And by 30 days in, most people aren't even trying to get the site back up anymore."
Will Larson
▶ 01:04:37

The value of the "never rewrite" rule, for Larson, is that it lets you veto a project that otherwise looks strategically justified. It is also why PMs need to push back when engineering managers phrase rewrites as "interesting work" or bury them in sentences like "you keep prioritizing this rewrite into a new programming language." The rewrite is the purest form of greenfield engineer satisfaction, and its visibility to PMs is systematically low.

When This Applies

— when the thesis looks reasonable on paper but the real driver is engineers wanting greenfield work and there is no migration plan. Digg v4 had a defensible thesis and still shipped into a dark production site. Use Fournier's diagnostic question out loud, in the room.

The Right Unit Is Not "The System" — It's the Cruft Inside It

Jay Baxter

Jay Baxter — Founding ML Engineer and Researcher for Community Notes at X (Twitter). Built one of the most impactful trust-and-safety products on the open internet; Community Notes has now been adopted or imitated by Meta and others.

Baxter holds the most interesting middle position in this debate, because he lived through the Elon-era X re-architecture and is willing to say, carefully, that a version of it actually worked. His framing starts from a specific pathology: A/B-test wins are measured in a one-month window, but maintenance costs compound over years. Teams systematically under-value the long-term cost of keeping marginal features alive.

"So often maybe due to promotion incentives or just regular human tendency, engineers have a tendency to add these little incremental wins that actually add more of a long-term maintenance cost than is clear, because you just run a little one month A-B test, you see this significant win and you don't realize the maintenance burden you just added to your team for the rest of eternity until you turn the thing off."
Jay Baxter
▶ 01:04:20

After the Twitter layoffs, the Community Notes team was forced into an audit they would never have done voluntarily: walking through the system, identifying parts whose maintenance burden exceeded their ongoing contribution, and cutting them.

"So I think there's a lot to be gained and you get forced to do this, by the way, when you have such a small team. It's just auditing parts of your system and deleting the things where the maintenance cost is worse than the gains. So I think we did have to do this across the company after the big layoffs, and systems are leaner now and they can be worked on by fewer numbers of people."
Jay Baxter
▶ 01:04:40

His most precise formulation is also a direct correction of the "Elon threw the whole thing away" narrative. The actual intervention was selective, and the right frame is not rewrite-versus-evolve but component-level honesty about what is still earning its keep.

"You don't have to rewrite everything from scratch. Some things are good, I guess, to rewrite. But just even deleting the unnecessary cruft and keeping the rest of the core system, that's awesome."
Jay Baxter
▶ 01:05:11

The implicit model is a spectrum. On one end is the greenfield rewrite everyone warns against. On the other is the incremental evolution that becomes a graveyard of half-maintained features no one will own. Baxter's claim is that the interesting move is in the middle: aggressive deletion of cruft combined with selective rewrites of components whose core abstractions are actually wrong, while leaving intact the parts of the system that still earn their keep.

When This Applies

— when the business is compounding on top of the existing system, subsystem boundaries are clean enough to uplift behind stable interfaces, and the dominant risk is losing undocumented business logic during migration. Fournier's recommendation-engine uplift and Perplexity's "only touch tech debt that unlocks capability" model both live here.

The Anti-Rewrite Rule Was Downstream of Scarcity — AI Just Broke It

Dhanji R. Prasanna

Dhanji R. Prasanna — Chief Technology Officer of Block, overseeing 3,500+ engineers. Author of the Block manifesto that drove a major internal reorganization around the Goose AI agent; one of the most senior CTOs publicly pushing the AI-native enterprise thesis.

Prasanna offers the most aggressive contrarian position in the archive, and importantly, he is not naive about the classical argument. Lenny surfaces it explicitly in their conversation — you are going to forget all the small improvements and bug fixes — and Prasanna engages with it directly. His core move is to argue that "don't rewrite" was never a law of software. It was a consequence of economics. Historically, rewriting was expensive because humans were expensive, coordination was slow, and every line of institutional knowledge had to be re-derived by hand. Under those constraints, the anti-rewrite heuristic was rational. But AI agents collapse the cost of generation and re-derivation toward zero.

"I think that you're going to see instead of us, for example, refactoring an app to have a different UI or to evolve into its new version, we're just going to rewrite that app from scratch. And one of the things I'm really pushing our teams to think about is what would our world look like if every single release, RM minus RF deleted the entire app and rebuilt it from scratch?"
Dhanji R. Prasanna
▶ 00:35:00

He is clear this is directional rather than currently possible, but he already has his own day-to-day evidence: he still writes code, and now regularly throws away huge amounts of it in ways that used to feel unnatural.

"I write code every day, but one of the things that I do regularly is just throw away huge, huge amounts of code, and it's kind of hard for me because I've never done that before. I mean obviously engineers love deleting code, but this is different. You build a whole new system or a whole new feature and you're like, 'Ah, it doesn't feel exactly right. I'm just going to delete and start over.'"
Dhanji R. Prasanna
▶ 00:34:34

The single most important move in Prasanna's argument is his answer to Fournier's strongest point. If the classical objection is that legacy code encodes tacit knowledge nobody has written down, then the AI-native counter is not "ignore that knowledge" — it is "move it out of the code and into a specification that AI can execute." The specification, the tests, and the accumulated bug fixes become the durable artifact; code becomes ephemeral output, regenerated each cycle.

"I think that the trick is getting the AI to respect all of those incremental improvements, yeah, and sort of bake those in as a part of the specification, if you will."
Dhanji R. Prasanna
▶ 00:36:09

This flips Fournier's argument on its head. Her claim that legacy systems encode undocumented knowledge becomes, in Prasanna's frame, an indictment rather than a defense. Undocumented tacit knowledge trapped in code you cannot read is a liability. The rewrite rule was protecting teams from a cost that used to be high and is now cheap.

When This Applies

— when you are in an existential competitive window and a rewrite would stack on top of a platformization and a GTM war. HipChat vs. Slack vs. Teams is the canonical cautionary tale.

Evidence from the Archive

HipChat / Stride

Atlassian's HipChat rewrite became Stride — by the time it shipped, Slack was miles ahead and Atlassian ultimately sold both to Slack

Tanguy Crusson lived through the failed rewrite that cost Atlassian the enterprise chat market; his advice now is absolutist: never do a rewrite

Tanguy Crusson · Head of Jira Product Discovery at Atlassian; former PM on HipChat and Stride ▶ 00:16:15

Digg

Digg v4 launch day: caterers, sushi, and champagne flutes around a table of engineers — because the site was not up. It took a month to come back

Will Larson lived through one of the most famous rewrite failures in startup history, driven by a genuine capability gap (social features) — and it still killed the company

Will Larson · Engineering executive at Calm; ex-Carta, Stripe, Uber, Digg; author of An Elegant Puzzle ▶ 01:03:39

Community Notes / X

After Twitter's layoffs, the Community Notes team audited the system and deleted parts whose maintenance cost exceeded their contribution — a partial, deletion-driven re-architecture that worked

Jay Baxter argues the right unit isn't 'the system' but the components that no longer pull their weight — small teams are forced into this discipline that large teams rarely do

Jay Baxter · Founding ML Engineer and Researcher for Community Notes at X

Block

Dhanji Prasanna is pushing Block to live inside the assumption that every release should rm -rf the app and rebuild from scratch — using AI

His argument: the old anti-rewrite rule was downstream of human labor cost, and in an AI-native world specifications become the durable artifact while code becomes ephemeral

Dhanji R. Prasanna · Chief Technology Officer at Block ▶ 00:35:00

Rent the Runway / Two Sigma

Camille Fournier's diagnostic question that kills most rewrites: 'If I could leave this system alone for a long period without it harming my business, is it worth changing at all?'

Her argument is evolutionary: take pieces of the old system, uplift them, clean up tech debt in place — migration cost is almost always underestimated

Camille Fournier · Engineering executive at Two Sigma; author of The Manager's Path and Platform Engineering ▶ 00:19:14

The Synthesis

None of these five voices is actually arguing the simple question Spolsky posed. The real disagreement is about the right unit of change. Fournier says it is a subsystem. Crusson says it is your entire competitive position, and the answer is to not touch it. Larson says it is the engineering team's belief, which collapses within thirty days if the new thing does not work. Baxter says it is the individual component, and the move is deletion, not replacement. Prasanna says it is the release, and the code itself is the wrong thing to protect — the specification is.

The Unit of Change

What are you actually rewriting?

Fournier's Diagnostic

If you ignored this, would the business actually be harmed?

Stacked Hard Things

How many hard bets are you stacking on one decision?

Deletion as the Middle Path

Have you actually audited what's earning its keep?

The Coefficient Has Changed

Was the anti-rewrite rule protecting a cost that still exists?

Fournier says the unit is a subsystem. Baxter says it's a component (mostly deletion). Larson says it's team belief — which collapses within thirty days if the new thing doesn't work. Prasanna says it's the release and code itself is the wrong thing to protect. The real disagreement isn't rewrite-or-evolve; it's what the right unit of change even is.

Camille Fournier's question kills most rewrite impulses before they form. If the honest answer is no, the rewrite is an aesthetic project and you should stop. Most rewrites are disguised attempts to solve a non-technical problem with a technical solution — HipChat's real problem was Slack's PMF, not its platform.

Crusson's HipChat lesson isn't that rewrites are impossible — it's that a rewrite, a platformization, and a competitive war were each hard individually, and stacking all three at once was fatal. The rewrite was the one Atlassian had the most control over and should have refused. Ask which dependencies are real and which you chose.

Jay Baxter's post-layoff X audit found that deletion — not rebuilding — was the highest-leverage move. A/B-test wins are measured in one-month windows, but maintenance costs compound for years. The interesting move is rarely rewrite or evolve; it's honest component-level cruft removal that normal orgs never get around to without external pressure.

Prasanna's contrarian move: 'never rewrite' was never a law, it was a consequence of economics. Generation and re-derivation used to be expensive. If AI collapses that cost, the rule protects you from something that no longer exists. The test is whether specifications can reliably capture tacit knowledge — nobody has shipped this at scale yet.

Which Approach Fits You?

Answer 3 questions about your situation. We'll match you to the right approach.

Question 1

What is the honest answer to Fournier's diagnostic: if you left this system alone for a year, would your business actually suffer?

Question 2

What is the competitive context?

Question 3

How confident are you in your team's understanding of the old system?

Notable Absences

The Bottom Line

The insight underneath all of this: the rewrite question is really a question about trust. Fournier is protecting engineering managers from their own teams' ambition. Crusson is lending you his pattern-matching so you do not have to lose a product to get it. Larson is offering a specific image — sushi, champagne, a dark production site — to cache against a decision your team will otherwise rationalize into existence. Baxter is quietly admitting that most engineering orgs will not make these trade-offs without external pressure. The debate is not really about code. It is about which failure mode you find easier to recover from: the rewrite that never ships, or the legacy system that slowly becomes unshippable.

The newsletter archive suggests a quieter path most successful companies actually take. "How Miro builds product" documents a 60/20/20 split that treats tech debt reduction as a continuous line item, dynamically reweighted when legacy burden grows — so pressure for one giant catastrophic rewrite never builds up. "How Perplexity builds product" sharpens it: tech debt work is only prioritized when it unlocks a user-visible capability, which is exactly Fournier's staged-evolution alternative. "Introducing Core 4" offers the measurement discipline the anti-rewrite camp is implicitly demanding — tech debt repayment as a business metric rather than an engineering aesthetic, so teams can distinguish a healthy piecewise evolution from a vanity rewrite before committing the capital.

Sources

Camille Fournier — "The things engineers are desperate for PMs to understand | Camille Fournier (author of “The Manager’s Path,” ex-CTO at Rent the Runway)" — Lenny's Podcast, September 15, 2024
Tanguy Crusson — "Hard-won lessons building 0 to 1 inside Atlassian | Tanguy Crusson (Head of Jira Product Discovery)" — Lenny's Podcast, June 16, 2024
Will Larson — "The engineering mindset | Will Larson (Carta, Stripe, Uber, Calm, Digg)" — Lenny's Podcast, January 7, 2024
Dhanji R. Prasanna — "How Block is becoming the most AI-native enterprise in the world | Dhanji R. Prasanna" — Lenny's Podcast, October 26, 2025