The Ashes Have Intent: Phoenix Architecture and Spec Driven Development
Why the greatest advantage of startups is now available to everyone who's willing to let go
Chad Fowler published something this week that crystallized a truth I’ve been living for the past year. In “Regenerative Software,” he introduces what he calls the Phoenix Architecture, systems designed to burn and be reborn without losing their identity.
The central paradox he articulates is well put: The most durable systems of the AI era will be built from code that is meant to die.
It’s the escape hatch from a trap that has plagued enterprise software since its inception.
The Incumbent Curse
Here’s a pattern I’ve watched impact competitive advantage repeatedly.
A company builds something great on the state of the art in the moment. They succeed. They grow. They hire teams to maintain what they’ve built. They create processes to protect it. They develop intellectual property strategies to defend it. The codebase becomes a city, as Fowler puts it, with all the urban planning nightmares that implies.
Meanwhile, a startup appears with nothing to defend. No legacy. No sunk costs. No emotional attachment to architectural decisions made in the distant past. They build on today’s state of the art, move faster, and eventually displace the incumbent.
The incumbent’s curse isn’t that they built bad software. It’s that they built good software in the distant past, and then made the rational decision to preserve rather than regenerate.
Every year they maintain is a year they fall behind.
The Startup Advantage Was Always About Letting Go
What makes startups dangerous isn’t their funding, or their energy, or their willingness to work long hours. It’s their freedom from attachment.
They can ask: If we were building this today, with today’s tools, what would we build?
The incumbent struggles to ask this question honestly. Too much is invested in the answer being “exactly what we have, just incremental”.
GenAI Changes the Economics
Here’s what accelerates with generative AI, and why I think Fowler’s Phoenix Architecture isn’t just philosophy but an imperative.
When code is expensive to produce, the rational response is preservation. You optimize for longevity. You maintain. You refactor carefully. You upgrade incrementally.
When code becomes cheap to generate, this calculus inverts completely.
Fowler frames it: we’ve built entire professions, identities, and institutions around the assumption that code is scarce. Programmers as craftsmen. Codebases as cities. Refactoring as urban renewal.
But what happens when you can regenerate a component in an afternoon? When the cost of understanding legacy code exceeds the cost of replacing it? When maintaining becomes more expensive than rebuilding?
The startup advantage, building on today’s state of the art without attachment to decisions made in the distant past, becomes widely available.
Spec Driven Development: Farming the Ashes
This is where my own practice has evolved over the past year leveraging Spec Driven Development.
If Phoenix Architecture means designing systems to burn and be reborn without losing identity, then the specification is the identity that survives.
The ashes have intent. They’re meant to be farmed into the next iteration.
In practice, this means treating specifications as the durable asset rather than implementations. When I build something now, the artifact I invest in preserving isn’t the code, it’s the spec that defines what the code should do, how it should behave, what interfaces it exposes, what invariants it maintains.
The specification captures intent. The code is just one possible expression of that intent, valid in that moment in time. When the tools improve or the constraints change, regenerate.
Not refactor. Not upgrade in place. Regenerate.
What This Looks Like in Practice
Recently I needed to rebuild a significant part of a codebase. Under the old model, this would have been a months-long effort of careful surgery. Understanding the existing code, mapping dependencies, making incremental changes, testing extensively, and spending a lot of time ensuring nothing broke.
Instead, I spent time writing specs and having AI evaluate existing implementations to help inform that spec. Then I regenerated the implementation using Gen AI, guided by those specs.
The specs became the seed from which the phoenix rose.
The Discipline Is Different
This isn’t recklessness. Fowler is clear about this, and so am I.
Regenerative software requires more discipline than maintenance-oriented software, not less. You need:
Specifications rigorous enough to regenerate from. Vague specs produce random implementations.
Evaluations that define correctness independently of code. You can’t validate a regenerated component against the old component—you need to validate against the spec.
Cultural comfort with deletion. This is harder than it sounds.
Architectural boundaries that survive regeneration. If everything burns at once, you have chaos. The art is in defining pace layer, what regenerates weekly, monthly, yearly, or never.
The ashes have intent. Farm them.