On Chad Fowler's Phoenix Architecturestevekrouse.comview source<br>On Chad Fowler's Phoenix Architecture
June 30,2026
I kept hearing about Chad Fowler's<br>Phoenix Architecture, and after<br>Charity Majors' endorsement,<br>I figured it was worth an investigation.
The core premise: LLMs make code cheap to generate, so code should be<br>disposable.
The most compelling parts are the analogies to immutability:
Immutable infrastructure. Stateless services. Containers. Blue-green<br>deployments. Infrastructure as code.
These ideas all share a common premise: never fix a running thing. Replace it.
AI pushes this premise beyond infrastructure and into application code itself.<br>When rewriting is cheap, editing in place becomes risky. Mutation accumulates<br>entropy. Replacement resets it.
When you edit code in place, you're doing the software equivalent of SSHing<br>into a production server and tweaking a config file.
I whole-heartedly agree that mutating something low-level is bad. Regenerating<br>it from scratch from something high-level is good. This is how we moved from<br>JQuery to ReactJS or from Binary to Assembly to C to JavaScript – higher level<br>abstractions that let us generate disposable lower level artifacts.
But that begs the question: regenerate from what? I sure hope you don't mean<br>natural language specs! Don't make me get the comic out again.
I made this case at length in<br>Reports of code's death are greatly exaggerated,<br>but in brief: natural language is a terrible "source of truth" for software. As<br>Bertrand Russell says, "Everything is vague to a degree you do not realize till<br>you have tried to make it precise." If today's code feels too low-level and<br>boilerplate-y in a way that makes you want to burn it down and regenerate it<br>from scratch, the fix is to climb incrementally higher to better programming<br>abstractions that let you convey your higher-level intent while still being<br>precise and mastering the inherent complexity.
It's a category error to conclude that because code is cheap to generate, we<br>should treat it all as disposable. It's leaning a bit too far into the vibes of<br>2025 and Gas Town, when designing around lots of slop seemed like the thing to<br>do. I don't know if we've yet hit peak code slop – probably not quite yet – but<br>it feels like that's right around the corner.
So while I don't agree with the solutions of the Phoenix Architecture, I do<br>agree with the problem:
The limiting factor is no longer writing software, but understanding,<br>evaluating, and governing it.
Peter Naur's<br>Programming as Theory Building, has<br>a similar theme: the code doesn't represent very much of the "theory" that made<br>it. However, Naur warns you against thinking you could put all that "theory"<br>into specs or docs. It lives in the heads of the creators.
But now that we have ephemeral machine "heads" – where does that understanding<br>live long-term? It kinda lives in the documentation that the machines write for<br>themselves, but at least for now, we all know that doesn't scale the same way<br>human understanding does.
For improving code understanding, I always return to Glen Chiacchieri's<br>A Human-Readable Interactive Representation of a Code Library,<br>a delightful explorable explanation of a fuzzyset library. (If you care at all<br>about code undersatnding, please go play with it!) Now with vibe coding, there's<br>very little excuse to not generate artifacts like these for every piece of<br>software we build.
My personal thesis is that making software understandable to humans also makes<br>it understandable to LLMs, and vice versa, so investments in understandability<br>do double-duty. This is great news! We can keep humans and machines both<br>in-the-loop at the same time. I think that's the path towards accelerating<br>development, and making the most of how cheap code is now to generate.