Notifications
Clear all
Topic starter
20/08/2026 5:29 pm
TL;DR: Architectural drift is the gap between intended software design and the structure that emerges as teams optimise for delivery speed, and Sonar says its architecture capability in SonarQube makes that gap measurable through complexity and dependency analysis. The real issue is that AI-assisted coding can accelerate structural entropy faster than manual reviews can catch it.
NHIMG editorial — based on content published by Sonar: architectural drift and maintainability analysis in SonarQube
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should teams stop architectural drift in large codebases?
A: Start by making architectural intent executable, not just documented.
Q: Why does architectural drift get worse when teams use AI code generation?
A: AI systems optimise for local correctness, not for your codebase's structural rules.
Q: How do you know if architecture controls are actually working?
A: Look for fewer forbidden dependencies, declining tangle counts, and lower duplication in new code rather than asking whether the whole codebase is perfectly clean.
Practitioner guidance
- Implement architecture rules on new code first Enforce dependency direction, allowed module relationships, and file placement only for new or modified code so teams can preserve delivery while reducing structural debt over time.
- Treat AI-generated code as untrusted until verified Run architecture checks after code generation and before merge so circular dependencies, duplicate logic, and forbidden imports are caught in the same workflow as the rest of the review.
- Use dependency maps to prioritise remediation Review the highest-risk tangles, cross-layer imports, and repeated logic paths first because they create the most expensive change cost and the hardest refactoring paths.
What's in the full article
Sonar's full article covers the operational detail this post intentionally leaves for the source:
- How the architecture capability models intended versus actual structure in the workflow
- How tangle detection and forbidden dependency issues are surfaced during analysis
- How teams can apply focus-on-new-code to reduce architectural debt incrementally
- How the capability fits into SonarQube Cloud for supported languages
👉 Read Sonar's analysis of architectural drift and the new architecture capability →
Architectural drift and AI-generated code: are your controls keeping up?
Explore further
20/08/2026 6:17 pm
Architectural drift is a governance failure, not just a code-quality issue. Once teams accept small boundary violations as acceptable shortcuts, the architecture stops being an enforceable design and becomes a retrospective narrative. That matters because control drift in software behaves much like identity drift in NHI programmes: rules exist on paper, but runtime reality diverges. Practitioners should treat structure enforcement as a governance control, not a developer preference.
A question worth separating out:
Q: What is the difference between documentation and enforceable architecture governance?
A: Documentation describes the intended structure, but enforceable governance checks the live codebase against that structure on every analysis. The difference matters because documents decay, while automated rules can block drift before it reaches production. In practice, governance is only real when violations create visible issues in the delivery workflow.
👉 Read our full editorial: Architectural drift is the maintainability gap AI code can widen
