An essay from The Phoenix Architecture argues that architectural knowledge lived inside the implementation for decades because the implementation was expensive to reproduce. That expense is disappearing — and as it goes, we find out how much of what we called “architecture” was really the cost of change wearing a disguise.

Cheap code was supposed to make architecture matter less. The essay’s case is that it’s doing the opposite: as implementation gets cheap, architecture becomes both more important and, for the first time, visible.

The regeneration test

  • “If I regenerated the system tomorrow and this changed, would I care?” — if no, it was an implementation choice masquerading as architecture (framework choice, cache swap, internal type organization).
  • If yes, ask why — the answer points at a boundary, invariant, authority, dependency rule, or safety property that gives the system its shape.
  • The test transcribes known architecture; regeneration failures expose unknown architecture you didn’t know you were carrying.

Architecture as constraints, not construction plans

  • “When code was expensive, architecture helped us build it. When code is cheap, architecture helps us reject it.”
  • Architecture is the set of constraints on how a system is allowed to change — whoever makes the change, person or agent.
  • Fitness functions participate in maintaining architecture: an ArchUnit rule rejecting an agent’s direct-to-ledger shortcut is the mechanical version of a diagram.

Two kinds of stability

  • Some decisions are hard to change because their meaning is embedded in the system; others because rewriting is expensive. Cheap regeneration separates intentional durability from accidental inertia.
  • Architectural gravity measures how much of the system’s meaning depends on a decision — data ownership being the canonical example — and generative tools barely touch it.
  • The danger cuts both ways: agents can remove an authority boundary in seconds, making a semantically significant change look mechanically trivial.

The theory has to live outside the code

  • Naur’s “Programming as Theory Building” (1985) still applies: the primary product is the theory of the problem, not the program text.
  • Agentic coding strips incidental learning — twenty files changed in ninety seconds leaves the team with a system that feels like something happening to it.
  • Constraints need provenance too: a rule nobody remembers the reason for is Chesterton’s Fence with a build failure attached.

The takeaway: regenerate the constraints and you get your system back; regenerate only the code and you get a different program that happens to pass the same tests. As implementation gets cheap, engineering value moves toward deciding what must stay true — and preserving that knowledge somewhere the code can’t take down with it.