The silent, incremental divergence between the architectural intent a team agreed to and the implementation that actually ships — accumulating over time, undetected by any standard review process.
What architectural drift is
Architectural drift is not a failure event. It does not produce a 3am incident. It does not generate a security finding or a customer complaint. It accumulates silently, and makes everything harder and slower over time.
An engineering team establishes architectural principles: service boundaries, data ownership rules, the event bus as the mechanism for cross-domain communication. Those principles are documented in ADRs, discussed in architecture reviews, encoded in the team’s shared mental model.
Then the team grows. Engineers join who were not in those discussions. The ADR that explained why the boundary exists becomes a file nobody reads. A developer opens a PR that crosses the boundary — not maliciously, but because they did not know the principle existed. The PR passes code review. The drift merges.
Architectural drift is the cumulative result of that process, repeated across hundreds of PRs over months and years.
Why it is chronic — and why it has become acute
Architectural drift has been a chronic pain for software organizations for two decades. Chronic pain does not make people change behavior urgently.
Engineering teams normalize it — the system is a bit messier than it should be, the boundaries are softer than they were designed to be, but it still works.
Engineering org surveys consistently rank architectural drift as the #1 pain point for engineering organizations — ahead of toolchain fragmentation, test coverage, and every other concern engineers raise. Those surveys were published before the current generation of AI coding tools became standard practice.
AI coding tools have converted the chronic pain into acute pain for organizations that have meaningfully adopted them. An engineering team generating 20 PRs per week from human developers is now generating 80 from AI-assisted developers. The 60 additional PRs carry no architectural memory. They do not know about the ADR that established the service boundary they just crossed. They do not know about the compliance constraint added six months ago.
The rate of potential drift events has multiplied. Review capacity has not.
What makes it hard to detect
Standard code review tools do not detect architectural drift. They detect code quality issues, dependency violations that can be expressed as package rules, and structural patterns. Architectural drift is a different category of violation.
What standard tools catch vs. miss
| Tool | Catches |
|---|---|
| SonarQube | Cyclomatic complexity, known code smells, test coverage gaps |
| ArchUnit | Package dependency rules you expressed as test assertions |
| Code review | What the reviewer knows to look for |
| None catch | A decision that violates a principle that was never expressed as a code rule |
The governing principle that established the boundary is in a Confluence page, an ADR, or the institutional memory of three engineers who were in the meeting two years ago. None of that is queryable by a linter.
How rkito addresses it
rkito’s approach to architectural drift operates across three layers.
Captures the principles that define what good looks like — ADRs, policies, patterns, compliance constraints — and converts them into Lenses: operational evaluation criteria that can be applied per PR.
Maintains the current design state — systems, components, interfaces — so the CDA knows what the architecture is supposed to be, not just what the code currently does.
Evaluates every PR against the Lenses derived from Steering. If a PR introduces drift without an approved Change Intention, it is blocked — not flagged, blocked — and an architect is notified.
Architectural drift is the silent, incremental divergence between the architectural intent a team agreed to and the implementation that actually ships — accumulating over time, undetected by any standard review process.