I feel like many of us in the Sysadmin Era (including you I bet?) were doing what is now called IaC or immutable infrastructure or what have you. We called it different things like “centralization of configuration” or “single source of truth” or just “that script which sets up/fixes machines”. Most of the talks at LISA were about some facet of that approach, and most tech companies of that era had teams developing tooling of that type for both production servers and user PCs. What happened imho was less that we all became cattle ranchers -- we already were! -- and more that we standardized around some cattle management tools.

(The pets/cattle metaphor always makes me sad though. Why do we embrace mass subjugation of living beings as our north star?)

And in fact I'd say that in any discipline of complex systems management there's The Artifact, or often The Small Number Of Artifacts We Keep In Sync With Great Effort, at the top of a chain of artifacts and processes that get rebuilt from that one with varying amounts of effort. Ask someone who project manages a major film production or construction project about their job and you will see so, so many parallels. There are 7,000 year old quarries in Egypt you can visit to see carvings of obelisk delivery schedules and change records. (Talk about immutable! as in literally written in stone! My tour guide was a little bemused at how fascinating I found those…)

Anyway I don't love-love the framing of “rip and replace, not mutate in place” as the core principle here. I tend to see that as an optimization and simplification tradeoff. I think the important thing is more the downhill flow of intention from The Artifact. The GPL defines source code as “the preferred form of the work for making changes to it”, nicely floating above the question of whether that's assembly code or typescript or Terraform files or shot lists or LLM prompts.

So through my own dusty and poorly focused lens, what you and Other Fowler and honestly all of us are grappling with is: given LLM tools, what is the preferred view on a system for making changes to it?

The UML advocates and the Intentional Programming team and formal-methods acolytes and schema-ontologists have been trying to lift above the grimy gritty muck of “grammar-parsed compiler input text files in a tree, plus some semi-out-of-date very-incomplete docs everyone agreed should be better but nobody made better” into some sort of glimmering Minority-Report transparent-glass concept representation, becsuse surely? Of course they didn't have Claude Code Fable 5 oops-nevermind-Opus-4.8 to monkey’s-paw that gritty muck around in line with the glimmering concept web…

BUT that gritty muck has some staying power and I'm not sure I'd count it out even now, in part because LLMs are trained around changes applied to gritty muck with verification guardrails, not around glimmering concept webs, nor around written natural language as the preferred form. So the Phoenix Architecture is intriguing but I need to see how it plays out in practice in the ugly reality of an actual product with warts and users and history.

That said the premise in the title of your piece certainly rings true, though I'm still unconvinced that the clankers won't be just as good at architecture-astronauting and guardrail-managing as we meatsacks are. I'm still fondling the stones I'll put in my pockets to walk into the sea when I'm fully convinced I really am obsolete, any day now…