The three failures of traditional architecture practice at AI scale
Architecture practice as it was designed assumes a pace: design decisions arrive in discrete, reviewable batches. Architects read ADRs, attend design reviews, mark up diagrams, and stay current. That assumption no longer holds. AI coding tools have decoupled the rate of structural change from the rate of human review. The practice has not kept up because it cannot — not without different infrastructure.
Architecture diagrams and ADRs exist. They are consulted on request, ignored in practice, and stale the day a PR merges. No mechanism connects them to the code that violates them. An ADR is a document in a wiki. The PR that breaks it is merged by an engineer who may never have read the wiki. These two facts coexist indefinitely without resolution until something fails.
Ask a chief architect what the actual current state of their system is and you will get the last diagram someone updated, the last ADR written, and their best recollection. The real system state — every boundary, dependency, component, and interface as it currently exists — is unknown. It is distributed across thousands of PRs nobody has aggregated. The architect is operating from an approximation, and the approximation degrades every sprint.
At AI coding velocity, the architect cannot be the human gate on every significant PR. The arithmetic does not work: one architect can meaningfully review 10 PRs per day. At 80 significant PRs per week, that covers 12% of the volume. The architect either becomes a bottleneck — holding back delivery to maintain coverage — or they are excluded from the process and design intent governance disappears entirely. Neither is acceptable. Both are common.
What this looks like in practice
These are not hypothetical failure modes. They are the normal operational state of any organisation running AI-assisted development without architectural enforcement infrastructure.
A major service refactor introduces 14 cross-boundary dependencies that violate the agreed microservices topology. None were reviewed. The discovery happens in a production incident six months later. Remediation requires unwinding changes that six months of subsequent work was built on top of.
An ADR you authored 18 months ago established a pattern for handling external API integrations. Forty PRs have since violated it. You do not know because there was never a mechanism to check. The violations are now a de facto standard the team believes is correct.
A new engineer asks what a specific service boundary looks like right now. You cannot answer from current data. You point to a diagram that was accurate when it was drawn. You add a caveat that things may have changed. They have.
You are asked to advise on a new feature's architectural approach. Before you can give one hour of considered advice, you spend two hours re-reading code, tracing dependencies, and reconstructing what the system actually contains. Most of that time is pure overhead — work that a continuously updated Architecture Ledger would have eliminated.
KPIs you cannot answer but should track
Architecture practice has no metrics because its outcomes have historically been too diffuse to measure directly. At AI scale, the absence of metrics is not a methodology choice — it is an operational blind spot. These are the four numbers that describe the health of an architecture practice. Most organisations cannot answer any of them.
How current is your verified understanding of the system's architectural topology? Not the last diagram. Not the last ADR. The actual, confirmed current state derived from code.
What percentage of PRs were checked against the ADRs applicable to the code they touched? For any team without automated conformance, the honest answer is zero.
How fast is the system diverging from its intended design? Is drift accelerating or decelerating? This is currently unknowable for most teams without continuous measurement.
What fraction of PRs does an architect's direct involvement actually reach? The remaining 85–90% ship with no architectural oversight at all.
How rkito scales the architecture practice
The architecture practice does not need to get faster. It needs the enforcement and memory functions to be handled by infrastructure that does not have a cognitive ceiling. rkito provides four specific capability shifts.
The Architecture Ledger is continuously updated by every CDA run. Every boundary, component, dependency, and interface is derived from the actual code — not a diagram. The system state is not stale by definition. When you need to know what the system contains, the answer is current.
Steering policies are authored once — AI-assisted, with the architect directing and the system drafting — and assembled into Lenses — curated, scoped views of the Steering corpus tailored to specific teams, services, and delivery contexts. The CDA evaluates each PR against the Lenses applicable to that code’s context. Not the entire corpus; the relevant subset, assembled by the architect’s design. The architect does not need to be present at every review. The Lens they authored is present. Every PR is evaluated against the right body of design intent, not the fraction the architect had time to check.
ADRs in rkito are not documents. They are translated into Steering policies and checked at every gate. An ADR you authored 18 months ago is as active as one you authored yesterday. The enforcement does not decay. It does not depend on whether the engineer submitting a PR read the wiki.
The architect is called only when CDA surfaces a genuine decision — something that requires judgment rather than pattern-matching. That call arrives with full context: the specific drift detected, the policy triggered, the relevant history. Not a Slack message. A structured request with everything needed to decide.
The context no architect holds in memory
When an architect reviews a PR, they need to know more than what the diff contains. They need to know which ADRs apply to the services being touched. What the current Architecture Ledger shows for those components — what dependencies already exist, what boundaries are active. What decisions were made for similar patterns in adjacent services. What the downstream impact of this change is likely to be.
No architect holds all of this simultaneously. The honest review process is: read the diff, consult memory, check the wiki if there is time, ask a colleague, make a call. The quality of the decision depends heavily on which contextual pieces were actually retrieved before the call was made.
rkito is the knowledge continuum the architect draws on during design review. When CDA surfaces a finding, it arrives with the applicable Steering policies, the Architecture Ledger state for the affected components, the history of prior decisions on similar patterns, and the downstream risk surface. The architect is not assembling context before they can give advice. The context is already assembled. They evaluate and decide.
- —Re-read the diff from scratch
- —Recall which ADRs apply — from memory
- —Check wiki for relevant policies (if current)
- —Reconstruct affected component topology
- —Ask colleagues for context on prior decisions
- —Give advice from a partially assembled picture
- —Diff with the specific drift already identified
- —Applicable Lenses surfaced — with the specific Steering artifacts and directives they reference
- —Architecture Ledger state for affected components
- —Prior decisions on similar patterns, linked
- —Downstream risk surface, derived from the Ledger
- —One decision to make — with full context to make it
Your metrics — and where they can mislead you.
These are the rkito metrics that matter most to your role. Each one removes a blind spot. Each one can also be misused. Read both.
Whether the design rules you've established are being followed across the full PR volume — without you personally reviewing every PR. DCS is the automated answer to the question you can't answer manually at 50+ AI-generated PRs per week.
The CDA pipeline evaluates every PR against your authored Lenses and produces a pass/fail. DCS = aggregate pass rate. Breakdown by Lens shows which specific rules generate the most violations.
High DCS with low Governance Depth is not healthy — almost nothing is being checked. Watch GD alongside DCS. If GD grows and DCS stays high, the Lenses are effective. If DCS crashes as GD grows, investigate before adjusting.
How much of your architectural knowledge has been made enforceable vs remaining in documents no automated system checks. GD measures how many principles are now Lenses — evaluated on every PR.
Count of active Lenses at /steerings/lenses. Each is binary, versioned, pillar-linked. GD grows as you encode more intent into evaluable rules.
GD is gameable. 50 trivial Lenses = high GD, low diagnostic value. Also: in the agentic era, every active Lens is intent that rkito MCP loads into an agent's session. GD is the proxy for how much of your architecture agents follow by design rather than by instruction.
Which architectural domain is under the most conformance pressure right now — so you focus architect attention where conformance is actually declining, not where people are loudest.
Passing evaluations for a pillar's Lenses / total evaluations for that pillar's Lenses, per sprint. Navigate to /changecontrols/designaudits, filter by FAIL, cross-reference by pillarId.
Pillar owners competing on PCR may soften Lenses rather than improve conformance. If PCR improves while LPP (Lenses per Pillar) decreases, investigate whether Lenses are being deprecated rather than conformance improving.
On the roadmap
The following capabilities are in active development. They are listed here so chief architects evaluating rkito understand the direction of the product.
System topology with real-time health overlay. See where drift is occurring across all services — which boundaries are under pressure, which components are accumulating violations, where the highest-risk change concentration is right now.
Which ADRs are generating findings, which are dormant, and which were violated most frequently. The signal you need to understand whether your design intent is being heard or ignored — and which decisions need to be revisited.
Catch boundary violations as they are introduced at the PR gate, before they compound. Identifies when a change introduces a cross-boundary dependency that violates the agreed topology, flagged before merge.
When CDA escalates to an architect, it arrives as a structured request with full context — the specific drift, the triggered policy, the proposed resolution, the downstream risk. Not a Slack message. A request you can evaluate and act on.
The architecture practice does not need fewer tools. It needs tools that run at the pace the system is changing.
Right now, the system is changing faster than any architect can track. That gap is not a personal failure — it is a structural consequence of AI coding velocity meeting a practice built for a slower era. The answer is not to slow the tools. The answer is to change what does the tracking.
rkito is the infrastructure that changes that ratio. The Steering corpus holds the intent. The CDA enforces it. The Architecture Ledger tracks the state. The architect makes the decisions that require an architect — and only those decisions.
An architecture practice that cannot enforce its own decisions is not a practice. It is a library. rkito is the enforcement layer the library never had.