Architectural drift has a name. The response to it mostly does not.

Teams building with AI coding agents have assembled a set of practices that clearly belong together: writing decisions into architecture decision records, exposing them to agents, testing dependency directions in CI, blocking prohibited constructs, reconciling documentation against implementation. These are treated as separate tools and separate chores. They are not separate. They are one discipline, and the discipline needs a name before it can be reasoned about, taught, or bought.

Architectural drift prevention is that name. It is the practice of keeping AI-generated code aligned with a system's existing architectural decisions, constraints, and boundaries as software evolves.

Why the category appeared now

Architectural conformance used to be maintained socially. A new engineer wrote something that violated an unwritten convention, a reviewer said we do not do it that way here, and the convention propagated. Slowly, imperfectly, but it worked, because the number of implementation decisions per week was small enough for humans to transmit intent each time.

AI coding agents break that assumption in two ways at once. The volume of changes rises past the point where intent can be manually re-transmitted, and the contributor producing them does not accumulate institutional memory between sessions. The correction has to be re-delivered every single time, and eventually nobody has the capacity to deliver it.

The mechanism is now documented rather than assumed. The 2026 position paper Architecture Without Architects identifies five ways coding agents make implicit architectural choices, and finds that prompt wording alone produces structurally different systems for the same task. Its authors call the result vibe architecting. On the consequence side, the market has begun labelling the outcome: architectural technical debt is expected to reach 80% of all technical debt by 2027.

The problem is named. The discipline that answers it needs to be nameable too.

Architectural drift prevention is not architectural debt management

This is the contrast that defines the category, and it is worth stating precisely, because the two are routinely conflated.

Architectural debt management is remedial. It assumes divergence has already accumulated and asks how to measure, prioritize, and pay it down. Its instruments are static analysis over an existing codebase, debt dashboards, refactoring programmes, and migration planning. Its unit of work is the remediation.

Architectural drift prevention is not architectural debt management, because it operates before the divergence exists rather than after. Its unit of work is the individual change, evaluated against the decisions that already govern it. A team doing debt management well still accumulates debt and pays it down efficiently. A team doing drift prevention well accumulates less of it.

Both are necessary. Neither substitutes for the other. But a strategy consisting only of the first is a strategy of paying interest.

Why writing it down is not enough

The intuitive response to drift is documentation. Write the decision into an architecture decision record, put a summary in the repository instruction file, and the agent will follow it.

This helps and it does not close the problem. A decision expressed as prose in a file has to survive a long probabilistic chain before it changes an implementation: it has to be loaded, retrieved as relevant, kept through context management, interpreted as intended, and then acted on. Research on context compaction has found that standing constraints are dropped at high rates while the task they were meant to govern survives intact, which is a structural weakness rather than a tuning problem. Context improves recall without making a constraint binding.

Availability and enforcement are different system properties. Architectural drift prevention is the discipline that treats them as different.

The architectural drift prevention stack

Approaches in this category can be arranged as a lifecycle. Most teams implement some of it accidentally. Very few implement all of it deliberately.

  • Capture. The decision is recorded as a decision, with its rationale, rather than surviving only in the heads of the people who made it.
  • Formalize. The decision is expressed in a form something other than a human can evaluate.
  • Scope. The decision names where it applies: which paths, packages, layers, or constructs it governs. A decision without applicability is documentation.
  • Retrieve. The decisions relevant to a specific change are selected, so relevance is computed per change rather than per session.
  • Inject. Applicable decisions reach the agent before implementation, so the work starts inside the constraint rather than being corrected toward it.
  • Enforce. Constraints that can be expressed mechanically are evaluated against the proposed change, producing the same verdict every time.
  • Detect. Divergence that escapes enforcement is surfaced rather than discovered during a migration.
  • Reconcile. When implementation and intent diverge legitimately, the decision is updated deliberately, rather than the divergence becoming the new de facto architecture.

The last step is the one most implementations omit, and its absence is why architectures quietly become whatever the code happens to do.

How it relates to adjacent approaches

Architectural drift prevention is a category, so most existing tools sit inside it rather than beside it.

  • Prompt engineering and instruction files implement capture and injection, probabilistically. They are the cheapest entry point and the weakest guarantee.
  • Retrieval and context systems implement retrieval well and enforcement not at all. Surfacing a decision is not the same as making it binding.
  • Linters and architecture-fitness tests implement enforcement for a narrow, pre-encoded rule set, usually without the decision or its rationale attached.
  • Spec-driven development strengthens capture and formalization by making the specification the primary artifact. It addresses what should be built more than which existing decisions constrain how.
  • Code review implements detection, late and at human cost, and remains the right instrument for everything that resists formalization.
  • Architectural governance implements the scope, inject, and enforce steps as a system rather than as separate tools, which is the part of the stack most commonly missing.

Reading these as competitors is a mistake. Most teams need several of them, and the useful question is which steps of the lifecycle are currently unowned.

How to measure it

A discipline that cannot be measured stays a preference. The measures that matter here are:

  • Architectural compliance rate. The proportion of changes conforming to the decisions governing the code they touch.
  • Violation rate and propagation. Whether a violation stays an incident or becomes precedent that later changes build on.
  • Scope expansion. Whether changes stay inside the boundary of the task.
  • Functional completion. The control measure. A mechanism that improves compliance while degrading delivery has not solved anything.
  • False-positive rate. Enforcement that blocks legitimate work gets disabled, which makes precision a survival property rather than a nicety.
  • Persistence across trajectory length. Compliance measured at task one versus task ten. This is the measure most often skipped and the most diagnostic.

Where Mneme fits

Mneme is one implementation of architectural drift prevention, not the definition of it. It concentrates on the scope, inject, and enforce steps: keeping architectural decisions in a durable corpus outside the conversation, selecting the ones applicable to a given change, and evaluating proposed changes against them deterministically.

That is a deliberate choice about which part of the lifecycle is least well served, not a claim that the other steps do not matter. A team could practise architectural drift prevention seriously with entirely different tools, and the category is more useful to the industry if it stays neutral about which.

Related concepts

Architectural drift prevention is the category. The concepts below are the mechanisms inside it:

  • Architectural drift — the failure mode this discipline exists to prevent, and the reason the category needed a name at all.
  • Architectural governance — the system that implements the scope, inject, and enforce steps of the stack as one mechanism rather than several tools.
  • Governance before generation — the posture that moves enforcement ahead of review, so the first violation is never written.
  • Decision continuity — the property that keeps a decision operative after the session, context, or agent that carried it is gone.