Greenfield Is the New Default — How AI Rewrote the Build-vs-Rebuild Decision

For twenty years, the safest advice in software was simple: don't rewrite. Extend what works. The most-quoted essay on the subject — Joel Spolsky's "Things You Should Never Do" — used Netscape's ground-up rewrite as the cautionary tale, and a generation of engineers took the lesson to heart. Rewriting was how you threw away years of accumulated fixes and shipped nothing for eighteen months.

That advice was correct. It was also priced for a world that no longer exists.

The Hidden Assumption

"Never rewrite" was never really about code quality. It was about cost. Writing code — the scaffolding, the plumbing, the tests, the thousand small decisions between an idea and a running system — was the expensive part. When starting over meant paying that cost again from zero, the math almost always favored extending what you had.

AI changed the price of that exact line item. An agent can scaffold a service, wire the plumbing, generate the tests, and draft the migrations in a fraction of the time it used to take. The tax on starting over — the thing that made "never rewrite" true by default — has largely been paid down. (The measured gains cluster in exactly this kind of first-draft, greenfield work — controlled studies show large speedups there, and much smaller or even negative ones on complex changes to mature systems. Which is the point: greenfield is where the collapse pays off.)

So our default flipped. We now assume greenfield unless proven otherwise.

The Case for Greenfield

Start over, and you get the things that are painful to retrofit:

No legacy tax. No working around dead code, leaky abstractions, or a decade of accumulated cruft. You move at the speed of the idea, not the constraints of the old system.
Modern defaults from line one. Strict types, a current security posture, and observability built in — instead of bolted onto a system that never planned for them.
Architecture for today's problem. The old system was designed for yesterday's scale and yesterday's requirements. Greenfield lets you design for the constraints you actually have.
A codebase agents can read. A clean, conventional, well-typed system is easier for both humans and AI agents to work in — and that legibility compounds on every change after the first.

None of that is new. What's new is that you no longer have to spend six months earning it.

The Case for Brownfield

Here's the discipline that keeps this from being a hot take: greenfield-vs-brownfield was rarely a code-cost decision in the first place. The real cost usually lives in things AI doesn't touch. Keep what you have when the value is concentrated in one of these:

Data gravity. The code is fast to regenerate; migrating years of live production state — backfilling, reconciling in-flight traffic, surviving the cutover — is not. The moat is the accumulated state, not the source.
Undocumented domain logic. The old system silently encodes thousands of edge cases and hard-won fixes nobody remembers. AI writes new code quickly, but it can't reverse-engineer intent that exists only in runtime behavior. Sometimes the boring legacy code is the spec.
Certification. A system that's cleared SOC 2, an audit, or a regulator carries approval that a rewrite resets. The cost there isn't code — it's re-earning trust.
Integration surface. When many live consumers depend on the current contract, the value is the interface everyone relies on. Rebuilding means renegotiating every integration — a coordination cost, not a build cost.
Earned reliability. A system that's survived years in production is tested against reality. When failure is expensive, known-good beats maybe-better.

And the twist worth sitting with: the same AI that makes greenfield fast also makes extending legacy easier — it can read and explain the tangled old system for you. So the one argument people still reach for to justify a rewrite — "the old code is too gnarly to touch" — is the one AI just took away.

A Decision Guide

Default to greenfield. Then check for the conditions that override it. Ask five questions:

Is the value in the data, not the code — would migrating live state cost more than rebuilding the logic?
Is critical behavior undocumented, living only in the running system?
Is it certified or audited in a way a rebuild would reset?
How wide is the integration surface, and what's the cost of renegotiating it?
How expensive is failure — is earned reliability worth more than a cleaner system?

But notice what AI does to each signal. The migration machinery — pipelines, tests, fallbacks — is exactly the thorough work AI now makes far less costly, so data cutovers cost less to execute. AI can extract a first-pass spec from undocumented code, turning it into a discovery step. It compresses the evidence-gathering behind certification. And a wide integration surface or an expensive failure mode is an argument for a rolling release — standing the new system up behind the existing contracts and migrating consumers incrementally, with AI carrying the compatibility shims and shortening the loop from failure to fix. The signals still matter; they just bite less than they used to. The more that bite, the more brownfield wins — but the brownfield case is narrowing, not vanishing. If none dominate, start over and take the speed.

What This Looks Like in Practice

We recently worked through this call with a travel media network. They ran a fully managed data service, and their agency partners were pushing to make first-party data more portable — enough that a hybrid model, like some competitors were running, was on the table. The question: build externalization on top of the existing platform, or go greenfield for a new era of data externalization.

They chose greenfield — to build something more maintainable and AI-forward. What made that defensible wasn't optimism about the build; it was how they treated the one factor that usually forces brownfield. Data gravity and migration risk are the classic reasons not to rebuild. So they met them head-on: explicit migration mitigation plans, plus AI agents standing by to handle migration issues in real time as they surface. AI didn't just make the new system faster to build — it eroded the very moat that historically favored keeping the old one.

That work is still in flight, so we're not claiming a win. We're pointing at the logic: the decision turned on where the cost actually lived, not on a reflex inherited from a different era.

The Takeaway

"Never rewrite" was good advice for its time. Its time assumed writing code was expensive. If your build-vs-rebuild instinct hasn't been re-examined since agents started doing the typing, it's calibrated to a world that's gone. Default to greenfield — and keep brownfield for the cases where the value was never in the code at all.

Pando builds software that feels like a superpower. More at pando.codes.