Most of Your Architecture Was Just Expensive Code - The Phoenix Architecture<br>For decades, architectural knowledge lived inside the implementation, because the implementation was expensive to reproduce. That expense is disappearing. And as it goes, we're going to find out how much of what we called "architecture" was really the cost of change wearing a disguise.<br>Cheap code is supposed to make architecture matter less. It's doing the opposite. As implementation gets cheap, architecture becomes both more important and, for the first time, visible.<br>The argument about AI coding has moved fast.<br>A year or two ago, the interesting question was whether models could write useful software at all. Then it became whether they could complete features, navigate repositories, run tests, fix their own mistakes, and work for long stretches without someone watching over their shoulder.<br>For anyone working seriously with the current generation of tools, that argument is mostly over. They can produce a lot of code. Sometimes an astonishing amount.<br>The argument now is about what happens afterward.<br>You hear it more and more from people at the frontier of these tools: code generation is no longer the bottleneck. Verification is. The same conversations keep circling back to harness engineering, cognitive debt, apprenticeship, and whether architecture and design still matter when the programmer is increasingly an agent rather than a person. Martin Fowler has framed a live disagreement here. Maybe sufficiently capable models will eventually deal with whatever spaghetti we hand them. Or maybe the properties that make systems understandable to humans (modularity, naming, clear boundaries) matter just as much to agents.<br>Meanwhile, the people actually attempting highly autonomous software development are running into the walls.<br>Dex Horthy of HumanLayer has described trying to run a lights-off software factory. For a while it worked. Then, after several serious failures, the team reportedly got to the point where rebuilding parts of the system by hand was easier than recovering from what their agents had produced.<br>His argument, as reported, is stronger than "tests aren't enough." Tests can give an agent a reward signal in seconds. Most of the costs of bad architecture show up over months or years. Cohesion, conceptual integrity, whether an abstraction makes the next hundred changes easier — those are hard to compress into a fast oracle. His conclusion for right now is blunt: "we're stuck reading the code."<br>I think he's right about right now.<br>I don't think he's describing a permanent boundary.<br>The deeper problem isn't that humans stopped typing the implementation. It's that we spent decades letting architectural knowledge stay implicit in the implementation. Cheap code removes some of the friction that used to protect that architecture, and in doing so it makes architecture both more visible and more necessary.<br>What was architecture when change was expensive?<br>In Who Needs an Architect?, Fowler quotes Ralph Johnson's description of architecture as "the important stuff, whatever that is." Fowler follows that to a useful consequence: maybe architecture is the set of decisions developers wish they could get right early. The things people perceive as hard to change. One of an architect's jobs, he argues, is to eliminate irreversibility wherever possible.<br>The difficulty-of-change test has always been useful because important architectural decisions tend to pick up enormous consequences. Change the tenancy model, the authorization scheme, or the ownership of an important data set, and the effects spread everywhere.<br>But the history of software has quietly mixed together two very different reasons a thing can be hard to change.<br>Some decisions are hard to change because their meaning is deeply embedded in the system.<br>Others are hard to change because rewriting the implementation is expensive.<br>For a long time those looked like the same thing. A framework choice could shape a company for a decade because replacing it meant rewriting millions of lines of code. A database engine could seem architectural because migrating away from it might cost years of work.<br>Fred Brooks made a related distinction in No Silver Bullet, separating the essential difficulty of software from the accidental difficulty introduced by the machinery we use to build it. Generative systems are an unusually powerful solvent for some forms of accidental implementation cost. They do much less to the essential difficulty of deciding what a system must mean.<br>Then code generation gets cheap.<br>Suddenly some supposedly architectural choices become trivial to replace while others stay every bit as consequential.<br>Cheap code separates accidental irreversibility from intentional durability. Imagine regenerating a system tomorrow.<br>The new version uses a different HTTP framework. You probably don't care. It organizes internal types differently. Also fine. It swaps a cache for another...