DEV Community: Vasiliy Shilov

Code Is Not the Source of Truth. It's a Materialized View.

Vasiliy Shilov — Wed, 18 Mar 2026 23:46:27 +0000

A short piece about what happens to development when code stops being the center. More of a reflection: how we think, what we fix in place, and why speed is no longer the main constraint.

Introduction What this is about and why it matters now. The shift from "write faster" to "understand more clearly".
Code Is Not the Center Code as cache and as a projection of decisions. Source of truth is not files but invariants and intent.
Intent and Invariants What to fix before code and why. Decision first, then code - not the other way around.
Two Modes Flow and serialization: when something new is born, when clarity appears. How not to get stuck packaging the past.
Comprehension Debt We generate understanding but don't know how to keep it as a system. And what to do about it.
Equilibrium Architecture as a balance of forces: latency - throughput, flexibility - simplicity. Change = shift in space, invariants = boundaries.
One Formula Meaning is fixed, execution is computed, the system lives through the evolution of decisions.

1. Introduction

For the last six months I've had the sense that I'm not so much writing code as trying to get a feel for the invariants of development itself.

At first it looked like a local task: speed up development with AI without losing control. It seemed to be about tools - Cursor, models, pipelines.

Very quickly it became clear: tools aren't the problem at all.

The problem is undefined intent.

AI doesn't break architecture. It just makes its weak spots visible faster than you can paper over them. You used to be able to write by hand for a week and not notice the mess in your head. Now - ten minutes, and you already have an architectural mess in the code.

I stopped trying to "write faster". That's no longer the problem. AI simply removed it.

The problem now is different:

how well you actually understand what you're doing
how well you can say it
whether you have invariants, not just "seems fine"

And the most interesting observation: speed is no longer the constraint. The new constraint is clarity of thinking, sharpness of invariants, the ability to formalize intent.

This booklet is about where that leads: not another framework, but a shift of gravity. Code moves to the background. What we fix before code and how we keep the system within the bounds of understanding moves to the center.

In short: not "how to write better", but "how to make thinking a bit more engineering". And that turned out harder than any NestJS service.

2. Code Is Not the Center

We've lived a long time with the idea that code is the system. That if the code exists - the system exists. If we lost the code - disaster.

AI quietly broke that assumption. Not loudly, not declaratively - through practice.

Code became cheap. So cheap that losing it is no longer a tragedy. Not because code got worse, but because a layer above it appeared that used to be blurry.

Before: idea, discussions, code, workarounds, documentation (if you're lucky).

Now something else is taking shape: idea, invariants, boundaries, decision, execution, code.

That's where the main shift happens: code no longer explains the system, it only reflects it.

Code is not the asset. The asset is invariants and decisions.

Code is their projection. You can rebuild it.

If you have intent, invariants, constraints, decision graph - code becomes computable. Not in a magical sense, but in this sense: computation used to be expensive, so we fixed the result (code). Now computation is cheap - we can fix the description and rebuild the result.

A handy formula:

CHANGE_PLAN / DOSA / invariants - source of truth
code - materialized view
execution - computing system state

You're just applying to development what databases, functional systems, and distributed systems already do: schema and change log matter more than the current snapshot.

One important anti-pattern: "I made it pretty but lost understanding" - that's a real anchor. So the model needs one more invariant: if you can't verify and understand the result - it's invalid, even if it's "computable".

The reality of the system is slowly moving: it used to be "files + classes + functions", it's becoming "decisions + constraints + their evolution".

3. Intent and Invariants

Clean Architecture, DDD, Ports & Adapters - they define structure and boundaries. But the lifecycle of a decision - how it is captured, constrained, and evolved - remains implicit. The closest thing we have is ADR. But ADR turns decisions into documents. What we need is to turn decisions into system primitives.

When you start explicitly fixing intent, invariants, constraints, kill criteria - you don't get documentation. You get a decision graph. And at some point it becomes obvious: code is not the center of the system. Code is a projection of decisions.

Hence the next step. If decisions are primary, they can be versioned, checked, executed, tied to metrics. Then architecture isn't a set of layers, it's a system for managing decisions under uncertainty.

In practice it looks like this. First you form the context of intent: talk to people, gather the picture. Then - a dump of thoughts, into a chat or on paper. Then structuring: not "make it pretty", but "split by intent, invariants, boundaries, steps". One plan file, one execution step at a time, a separate context per step. The model gets not "everything at once" but the minimal sufficient slice. And that gives both quality and economy: moving along meaning is cheaper than recovering meaning through search.

The main observation: a separate chat - less context -> often better quality. LLM quality is proportional to the clarity of local context, not its size. A tree model fits: root -> intent and invariants, branches -> change plans, leaves -> execution steps. That's indexing by meaning, not by text.

The human is responsible for meaning and boundaries. The system (AI + runtime) - for execution. AI shouldn't define the system, it should live inside the frame we set.

4. Two Modes

There are two modes we slip into when we think and do.

Flow / exploration. That's where something new is born. No clarity, just "feels like something's here", contradiction is allowed.

Serialization / fixation. That's where clarity, words, boundaries appear. But almost nothing new appears there anymore.

The problem isn't that the second mode is bad. The problem is that it's very sticky. It gives a sense of control, completeness - "I did good, I packaged it". And you can sit in it for hours, days, and at some point catch yourself: you haven't discovered anything in a long time, you're just neatly packing the past.

The key skill isn't "write better", it's switching between modes on purpose. Almost like a toggle: now I'm exploring, now I'm fixing.

A strict rule helps: if you're in flow - don't try to make it pretty and correct right away. At most - short markers, anchors, scraps of thought so you can come back later. And only in a separate state: ok, now let's turn this into a plan, an article, an architecture.

And an important effect: if you do it that way, serialization stops "killing the flow" and starts feeding it. You return not to a void but to a space that's already a bit structured.

CIMP and similar things are basically an attempt to make even the fixed part not die but stay part of a living thinking process. Not a "memory dump", but a frame you can build the next loop on.

5. Comprehension Debt

You talk with someone - and it's great. But if you close the chat, half the meaning just vanishes.

We generate understanding but don't know how to keep it as a system. I call this comprehension debt - like technical debt, only in understanding. The term has been around in various circles for a long time, and I didn't coin it, but this name fits me best.

Any conversation with AI is ephemeral. It doesn't persist as a knowledge system. You kind of understood - but that understanding isn't anchored anywhere. Hence ideas like RAG, context graphs, structured artifacts. But even that's not enough: knowledge isn't text, it's the link between decisions, invariants, and consequences.

In the new model, documentation stops being "extra work". It becomes the main interface for controlling the system. Not an afterthought, but what execution loses its anchor without.

Formulating outward - articles, posts, plans - is a way to unload your head, check what matters, and make room for new things. Not a side effect but a natural extension of the same approach: structure lowers the cognitive cost.

One more thought: if you can't hold the system as a model - it doesn't exist. Doesn't matter how many lines of code. So fixing meaning isn't bureaucracy, it's the condition for the system to exist in your head and in the heads of everyone who works with it.

6. Equilibrium

Architecture works with a limited set of concepts and meanings. They're almost deterministic, what changes is mainly context. And there are concrete forces that are always being traded off.

Technical: compute vs data, latency vs throughput, consistency and availability.

Structural: flexibility vs simplicity, experimentation and research vs control.

Architecture isn't a choice of "what's better", it's equilibrium. Every change isn't a "feature", it's a shift of the system in the space of these forces. And if you have invariants, you limit where you can move. If you don't - the system just spreads.

It helps to think of it as vectors. The system is a point in the space of forces, a change is a shift of the vector, invariants are constraints on the allowed region. You start to see that system architecture and model architecture (the same vectors, matrices, parallel computation) aren't different worlds - they're the same math in different guises.

Splitting into two layers keeps the zones from mixing: deterministic (invariants, policies, boundaries, checkable rules) and probabilistic (AI, inference, generation, search). AI should live inside constraints, not define them. Then the human is responsible for meaning and boundaries, the system for execution.

In the end, development isn't writing code, it's managing the computation of decisions. And your workflow with plans, steps, and review stops looking like a hack and starts looking like a clean model: you generate intent, fix it, split into steps, execute one at a time, check, adjust. The main thing: you don't hold everything in your head at once. You build a system where moving along meaning is cheaper than recovering it.

7. One Formula

If you pack it all into one short formula:

Meaning is fixed. Execution is computed. The system lives through the evolution of decisions.

You're no longer trying to "write correctly". You're trying to make it so that even if you forget - the system can be restored. That's already very close to how math, physics, and stable systems in general work.

The shift is essentially:

was: code-centric engineering
becomes: decision-centric engineering

Like git for code - only for decisions. At some point I realized architecture isn't about diagrams. It's about taking a blurry thought and making it concrete enough to be checked, executed, and not lost a week later.

The final picture: not "speed up development", but make it observable, explainable, controllable, and scalable without losing meaning. Thinking becomes executable. And that's much deeper than it seems at first.

This idea doesn't stop here.

If code is not the source of truth, then:

what is?
how is it structured?
how does it evolve?

I'll explore this in the next short parts:

DOSA (Decision-Oriented System Architecture) - what happens when decisions become first-class system primitives, and architecture turns into a graph of evolving decisions rather than static structure
Context-oriented engineering - why smaller, structured context outperforms large prompts, and how to make context composable
Feedback-centric engineering - how systems close the loop between execution and understanding, and learn through decisions
System evolution - how systems become capable of change while preserving stability

Stop Using LLMs for Everything: The Power of Hybrid Architectures

Vasiliy Shilov — Sun, 08 Mar 2026 19:40:10 +0000

Over the past month my thinking about AI systems changed dramatically.

Many teams are quietly making the same architectural mistake:

They use LLMs for problems that should remain deterministic.

The result is predictable:

higher latency
higher cost
lower reliability
harder debugging

The irony?

Most intelligent systems don't need more AI. They need better architecture.

The common narrative today is simple:

Intelligence = large probabilistic models.

This assumption quietly pushes many teams into a dangerous design mistake: using probabilistic models for problems that should remain deterministic.

But when you start building systems that actually work reliably, a different picture appears.

Most practical systems are not purely probabilistic — they are architectures combining deterministic and probabilistic computation.

Understanding the difference between these two classes of computation turns out to be extremely important, not only for AI engineers but for system architects in general.

Where This Idea Came From

My perspective on this topic evolved through several stages.

First, years of writing software the traditional way — carefully designing deterministic systems where behavior is predictable and constraints are explicit.

Then the arrival of AI coding tools. Suddenly code generation became extremely cheap. Many tasks that used to require careful implementation could be produced instantly.

At first this felt like pure acceleration. But over time it became clear that cheap execution has a side effect: architectural drift.

This line of thinking started when I began exploring the hidden cost of cheap execution in AI-accelerated development (which I wrote about earlier in a LinkedIn post: "The Hidden Cost of Cheap Execution").

More recently I've been building tools that intentionally combine deterministic and probabilistic computation — applying probabilistic reasoning only where deterministic structure cannot reduce the problem space further.

This article summarizes the core principle behind that approach.

Two Classes of Computation

At a very high level, most computational tasks fall into two categories:

Deterministic computation
Probabilistic computation

They solve fundamentally different kinds of problems.

Property	Deterministic	Probabilistic
Output	fixed	distribution
Debugging	straightforward	statistical
Failure	explicit	uncertain
Cost	cheap	expensive
Use case	constraints	ambiguity

Deterministic Computation

Deterministic computation is what classical software engineering is built on. Given the same input, the system always produces the same output.

Examples:

compilers
parsers
type checkers
database queries
validation rules
cryptography
routing logic
protocol implementations
regular expressions (parsing, validation, extraction)

In deterministic systems:

output = f(input)

The function f is explicit, stable, and predictable.

Strengths

Deterministic computation is extremely powerful when:

rules are known
constraints are strict
correctness matters
behavior must be explainable
failure modes must be controlled

Properties:

predictable
debuggable
verifiable
cheap to run
safe for critical paths

This is why the core infrastructure of the digital world — databases, compilers, operating systems — is deterministic. No surprises. You can reason about it.

Limitations

Deterministic systems struggle when:

rules are unknown
inputs are ambiguous
the space of possibilities is huge
knowledge must be compressed from data

For example:

natural language interpretation
image recognition
semantic similarity
reasoning under uncertainty

These problems are hard to encode with explicit rules. That's where probability earns its place.

Probabilistic Computation

Probabilistic systems operate differently. Instead of explicit rules, they model probability distributions.

For example, a language model estimates:

P(next_token | context)

The system does not compute the answer through rules; it computes the most likely continuation.

Examples:

language models
speech recognition
recommender systems
ranking models
anomaly detection
computer vision models

Probabilistic systems are extremely powerful for problems where:

rules are unknown
data is noisy
patterns must be inferred

Strengths

Probabilistic systems are excellent at:

pattern recognition
generalization
handling ambiguity
synthesizing new combinations
compressing large knowledge spaces
when you don't have a spec, they're often the only option

This is why modern AI works at all. The catch: it doesn't tell you where to use it.

Limitations

But probabilistic systems have fundamental weaknesses:

non-deterministic outputs
hallucinations
difficulty enforcing constraints
limited explainability
cost and latency — model inference is expensive compared to deterministic logic

A regex, an if statement, or a database lookup executes in microseconds and costs essentially nothing. A model call costs money and introduces latency. At scale, this difference becomes a primary architectural constraint.

If used incorrectly, they introduce uncertainty into places where certainty is required.

The False Dichotomy

Many discussions today frame the problem incorrectly:

Should we replace deterministic systems with AI?

This is the wrong question. The real question is:

How should deterministic and probabilistic computation be composed?

Where Deterministic Computation Wins

Deterministic systems dominate when:

the structure is known
constraints exist
invariants must be preserved

Examples:

Programming languages — Compilers are deterministic for a reason. A probabilistic compiler would be catastrophic.
Databases — SQL engines are deterministic because queries must be correct.
Protocols — Network protocols rely on deterministic state machines.
Validation — Formats like JSON, protobuf, and schema validation require exact correctness.
Regular expressions — Same pattern and input always yield the same match. In hybrid systems they often do the first cut — extracting structure (dates, IDs, emails) from raw text before any LLM sees it. That reduces ambiguity and keeps the model away from tasks that don't need probability.

Where Probabilistic Computation Wins

Probabilistic systems dominate when the problem is inherently ambiguous.

Examples:

Natural language — Human language contains ambiguity everywhere.
Retrieval and ranking — Choosing the most relevant document is rarely deterministic. Ever tried to make that 100% rule-based? It doesn't scale.
Vision — Images are noisy and high dimensional.
Code synthesis — Generating new code often requires combining patterns probabilistically.

Deterministic Risk Control

Deterministic layers are where you enforce invariants and reduce risk. Probabilistic components don't get to override these rules.

Input validation — length, charset, schema (e.g. JSON schema). Invalid input never reaches the model.
Output validation — allowlists of actions, formats, or categories; length limits; PII checks. The model may suggest something, but only allowed values are executed or stored.
Regular expressions — extract and validate structure (emails, IDs, tags) before the model; same for checking model output against expected patterns.
Audit and idempotency — deterministic request IDs and idempotency keys ensure that critical actions are logged and not duplicated, regardless of model non-determinism.

I've seen codebases that sent every user message straight to an LLM. The bill and the latency told the story.

The rule of thumb: anything that would cause legal, safety, or data-integrity issues must be enforced in deterministic code, not in prompt engineering or "smarter" models.

Example: deterministic extraction before any LLM call:

function extractStructuredParts(userMessage: string): {
  emails: string[];
  ticketIds: string[];
  hasUrgent: boolean;
} {
  const emailRegex = /[\w.-]+@[\w.-]+\.\w+/g;
  const ticketRegex = /#(\d+)/g;
  const urgentRegex = /\b(urgent|asap|critical)\b/i;
  return {
    emails: userMessage.match(emailRegex) ?? [],
    ticketIds: [...userMessage.matchAll(ticketRegex)].map((m) => m[1]),
    hasUrgent: urgentRegex.test(userMessage),
  };
}
// Same input => same output. No model needed for this.

Example: deterministic guardrails on model output — only allowlisted actions are executed:

const ALLOWED_ACTIONS = new Set(["view", "edit", "submit", "cancel"]);

function safeExecute(modelOutput: string): string {
  const action = modelOutput.trim().toLowerCase().split(/\s+/)[0]; // e.g. "submit form"
  if (!ALLOWED_ACTIONS.has(action)) {
    return "error: unknown action"; // never pass through raw model output
  }
  return executeAction(action);
}

The Real Architecture: Hybrid Systems

The most powerful systems are hybrid. Instead of replacing deterministic computation, probabilistic models should operate inside deterministic scaffolding.

Deterministic logic defines the boundaries. Probabilistic models explore inside those boundaries. That is the metaphor worth keeping in mind.

Conceptually, the flow looks like this:

          Problem Space

┌──────────────────────────────┐
│                              │
│   Deterministic Reduction    │
│  (rules, validation, index)  │
│                              │
└──────────────┬───────────────┘
               │
               ▼
      Residual Uncertainty
               │
               ▼
     Probabilistic Reasoning
        (LLM / ML models)

Good architecture reduces the problem space deterministically before applying probabilistic intelligence.

A typical pipeline in code looks like this:

input
   │
   ▼
deterministic preprocessing
   │
   ▼
constraint reduction
   │
   ▼
retrieval / memory
   │
   ▼
probabilistic reasoning
   │
   ▼
deterministic validation
   │
   ▼
output

In code, that often looks like this:

// Hybrid: deterministic shell around probabilistic core
async function processUserRequest(raw: string): Promise<string> {
  // 1. Deterministic: normalize and validate input
  const text = raw.trim()
  if (text.length < 1 || text.length > 10000) {
    throw new Error('Invalid length')
  }

  // 2. Deterministic: extract known structure (e.g. with regex)
  const refs = [...text.matchAll(/#(\d+)/g)].map((m) => m[1]) // ticket IDs

  // 3. Probabilistic: only for the ambiguous part
  const response = await llm.generate({ context: text, refs })

  // 4. Deterministic: validate output shape and safety
  if (!response || response.length > 5000) {
    return fallbackResponse()
  }
  return response
}

In other words:

Remove everything that can be solved deterministically.
Narrow the search space.
Retrieve known information.
Use probabilistic reasoning only for the residual uncertainty.

Ports and Adapters: Structure Decides

The same pipeline fits naturally into a port-adapter (hexagonal) view. What matters is the structure — the ports and the flow — not whether a given step is implemented deterministically or probabilistically.

          ┌─────────────────────────────────────┐
          │         Application Core            │
          │  (orchestration, use cases, ports)  │
          └──────────────────┬──────────────────┘
                             │
     ┌───────────────────────┼────────────────────────┐
     │                       │                        │
     ▼                       ▼                        ▼
┌─────────┐ ┌──────────┐ ┌────────┐ ┌──────────┐ ┌─────────┐
│ Preproc │ │ Retrieve │ │ Reason │ │ Validate │ │  Output │
│  port   │ │  port    │ │  port  │ │  port    │ │  port   │
└────┬────┘ └────┬─────┘ └────┬───┘ └────┬─────┘ └────┬────┘
     │           │            │          │            │
     ▼           ▼            ▼          ▼            ▼
  adapter     adapter      adapter     adapter      adapter
  (determ.    (vector DB,  (LLM /      (schema,     (format,
  or LLM)     or rule)     or rules)   allowlist)   log)

The core depends only on ports (interfaces). Each adapter can be deterministic or probabilistic. You can replace a deterministic preprocessor with a probabilistic one (e.g. "normalize with an LLM") or the other way around — the architecture stays the same. Structure decides; implementations are pluggable.

// Port: the core only depends on this contract
interface ReasonerPort {
  generate(ctx: { context: string; refs: string[] }): Promise<string>
}

// Adapter A: deterministic (rules, template)
class RuleBasedReasoner implements ReasonerPort {
  async generate({ context, refs }: { context: string; refs: string[] }): Promise<string> {
    return applyTemplates(context, refs) // same input => same output
  }
}

// Adapter B: probabilistic (LLM)
class LLMReasoner implements ReasonerPort {
  async generate({ context, refs }: { context: string; refs: string[] }): Promise<string> {
    return llm.generate({ context, refs }) // same input => may vary
  }
}

// Application code is identical; swap the adapter to switch behaviour
const reasoner: ReasonerPort = new RuleBasedReasoner() // or new LLMReasoner()

So: the decision of where to use deterministic vs probabilistic logic lives in the choice of adapters, not in the core. The core defines what steps exist and in what order — that is what we mean by "architecture is the multiplier."

Residual Intelligence

The Residual Intelligence Principle

Probabilistic models should solve only the residual uncertainty after deterministic reduction of the problem space.

Good architecture does not ask AI to solve everything. It asks AI to solve only what cannot be solved deterministically. Get that wrong and you're paying for intelligence you don't need.

This dramatically reduces complexity and leads to:

cheaper systems
more reliable outputs
fewer hallucinations
easier governance

Example: Code Completion

Modern IDEs illustrate this hybrid approach well. Many completions do not require LLMs. They rely on deterministic information:

syntax
types
symbol tables
project index
scope rules

Only when the system cannot determine a clear continuation does it use probabilistic generation. This combination is far more efficient than using an LLM everywhere.

Extreme Cases

Understanding the extremes is also instructive: pure deterministic systems suffer from rule explosion, pure probabilistic ones from uncontrolled uncertainty.

Pure deterministic systems

Strengths: reliability, predictability, efficiency
Weaknesses: brittleness, inability to generalize, enormous rule complexity

Pure probabilistic systems

Strengths: flexibility, adaptability, pattern recognition
Weaknesses: instability, hallucinations, lack of guarantees

Most systems that "went full AI" learned that the hard way.

Architecture Is the Multiplier

The biggest performance gains rarely come from making probabilistic models bigger. They come from structuring the system correctly.

A well-designed deterministic layer can reduce the search space by orders of magnitude, so the probabilistic layer works on a much smaller and easier problem — and that is where nonlinear efficiency gains appear. One good deterministic filter can shrink the problem tenfold before the model ever runs.

A Different Way to Think About AI

Instead of thinking about AI as a replacement for software engineering, we can think about it as a new computational layer.

Not:

software => replaced by AI

But:

deterministic systems
      +
probabilistic models
      =
hybrid intelligent architectures

The future of intelligent systems is likely not pure AI; it is architecture — the art of deciding which parts of the system must be deterministic, and where probability should be allowed to exist.

Closing Thought

AI did not eliminate engineering. It exposed something deeper.

Execution was never the hardest problem. The real challenge has always been structuring the problem space so that expensive intelligence is used only where it is truly needed. That is the job of architecture.

One question

If you removed all deterministic layers from your system and replaced them with LLM calls...

would it become smarter — or just more expensive?

Clean Architecture in the Age of AI: Preventing Architectural Liquefaction

Vasiliy Shilov — Mon, 02 Mar 2026 00:21:21 +0000

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 solution space narrows.
Drift becomes detectable.
Structural violations surface earlier.
Local optimization cannot silently destroy global design.

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.

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

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.

DEV Community: Vasiliy Shilov

Code Is Not the Source of Truth. It's a Materialized View.

Contents

1. Introduction

2. Code Is Not the Center

3. Intent and Invariants

4. Two Modes

5. Comprehension Debt

6. Equilibrium

7. One Formula

Stop Using LLMs for Everything: The Power of Hybrid Architectures

Where This Idea Came From

Two Classes of Computation

Deterministic Computation

Strengths

Limitations

Probabilistic Computation

Strengths

Limitations

The False Dichotomy

Where Deterministic Computation Wins

Where Probabilistic Computation Wins

Deterministic Risk Control

The Real Architecture: Hybrid Systems

Ports and Adapters: Structure Decides

Residual Intelligence

The Residual Intelligence Principle

Example: Code Completion

Extreme Cases

Architecture Is the Multiplier

A Different Way to Think About AI

Closing Thought

One question

Clean Architecture in the Age of AI: Preventing Architectural Liquefaction