Tools: Clean Architecture in the Age of AI: Preventing Architectural Liquefaction

AI has made execution cheap; models optimize locally, not for architecture. In many teams the side effect is not bad code or broken builds, but something more structural: architectural liquefaction. Architectural liquefaction is the progressive loss of structural boundaries under sustained probabilistic code generation and accelerated change cycles. It does not happen in one PR — layer boundaries soften, dependencies cross the wrong way, contracts drift, invariants weaken, "temporary" shortcuts pile up. Everything still works. Until the cost of change quietly multiplies. Without explicit constraints, entropy grows as we ship faster. Clean Architecture is often described as a layering discipline. But in the context of AI-assisted development, it may serve a different purpose: a deterministic shell around probabilistic execution. Not dogma, not aesthetic preference — a stabilizing mechanism. When boundaries are explicit and dependency direction is enforced: The architecture becomes a control surface. Before AI, architectural violations required effort. A developer had to consciously decide to break a boundary. Now, violations can be generated in seconds. And because AI-generated code often "looks right", structural erosion is harder to notice. The real cost is not bad code in the moment; it's that the drift stays invisible until you hit a refactor that suddenly touches half the codebase. One more thing: the more “flexible” and underspecified your prompts and rules are, the faster liquefaction tends to happen — the model fills in the gaps in whatever direction is locally easiest. I once wrote down all our architectural principles — boundaries, dependency rules, what lives where — into a docs/ folder in plain Markdown, then wired them into Cursor as project rules so they get injected into every prompt. Before that, Cursor would often put repository calls straight into controllers or leak infrastructure imports into the domain layer — it just followed the patterns it saw in the codebase. After the rules were in place, it started routing through use cases and keeping adapters out of core. Still not perfect: sometimes it over-engineers or picks the wrong abstraction. But the rate of cross-layer violations dropped sharply. The model had something to optimize for instead of only optimizing for "code that runs". That is one data point. It fits the hypothesis: explicit boundaries plus enforcement reduce structural drift, even when the code is AI-generated. To make this testable we'd need drift metrics (e.g. dependency violations, cross-layer calls), review cost over time, and refactor scope when fixing violations. The hypothesis would be falsified if teams with strict rules drift as much as others, or if review and refactor cost keep growing despite enforcement. I'm preparing concrete ways to define and track these — drift metrics and cost — for follow-up posts. Clean Architecture is usually framed as boundaries, inward dependencies, business logic isolated from the rest. True enough — but in an AI-heavy workflow the useful way to see it is: probabilistic execution, deterministic governance. We are not removing uncertainty. We are putting a box around it so that the model's choices stay inside the box. The architecture becomes the box. If you are using AI heavily in development: are your boundaries getting stronger or weaker? Is the cost of keeping the structure in your head going up or down? I don't have a conclusion yet — only a hypothesis. AI has optimized execution; whether we've optimized stability, or are just producing entropy faster, is open. Obvious structures are often the first to dissolve when everything speeds up. In the next posts I'll look at other ways to keep things from liquefying. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK:
tree ./docs/
.
├── ARCHITECTURAL-STYLE-GUIDE.md
├── CLEAN-NEST-APP.md
├── architecture
│ ├── adapters.md
│ ├── core.md
│ ├── controllers.md
│ ├── events.md
│ ├── inter-module-communication.md
│ ├── modules.md
│ ├── structure.md
│ ├── testing.md
│ └── when-to-simplify.md
└── guides ├── cheat-sheet.md ├── common-patterns.md └── quick-start.md Enter fullscreen mode Exit fullscreen mode CODE_BLOCK:
tree ./docs/
.
├── ARCHITECTURAL-STYLE-GUIDE.md
├── CLEAN-NEST-APP.md
├── architecture
│ ├── adapters.md
│ ├── core.md
│ ├── controllers.md
│ ├── events.md
│ ├── inter-module-communication.md
│ ├── modules.md
│ ├── structure.md
│ ├── testing.md
│ └── when-to-simplify.md
└── guides ├── cheat-sheet.md ├── common-patterns.md └── quick-start.md CODE_BLOCK:
tree ./docs/
.
├── ARCHITECTURAL-STYLE-GUIDE.md
├── CLEAN-NEST-APP.md
├── architecture
│ ├── adapters.md
│ ├── core.md
│ ├── controllers.md
│ ├── events.md
│ ├── inter-module-communication.md
│ ├── modules.md
│ ├── structure.md
│ ├── testing.md
│ └── when-to-simplify.md
└── guides ├── cheat-sheet.md ├── common-patterns.md └── quick-start.md - The solution space narrows.
- Drift becomes detectable.
- Structural violations surface earlier.
- Local optimization cannot silently destroy global design.