An open-source tool called Archfit addresses architecture erosion accelerated by AI coding agents, which can produce code that passes tests and linters while quietly violating module boundaries. Archfit reads declared architectural intent from a YAML config, checks it against actual code dependencies, and fails CI when violations occur, producing machine-readable repair tasks agents can act on. The approach draws on Vlad Khononov's Balanced Coupling model, scoring relationships by integration strength, distance, and volatility, and is framed as a structural sensor rather than a full architecture judge—it cannot detect business-logic issues, catch a misconfigured policy, or replace human decisions about when intent should change. It targets repositories with deliberate module boundaries and heavy agent-driven change, and is open source under Apache-2.0 on GitHub.
Table of contents
The Problem Is Governance, Not Code GenerationI Tried the Obvious ThingsArchfit in 90 SecondsWhat Is Different Here?Faster Change Needs Faster FeedbackGet Alexei Ledenev ’s stories in your inboxModularity Is Context Engineering for CodeCoupling Is Not the EnemyWhat Archfit Cannot GovernWho Is This For?Further ReadingTry It Without Trusting ItQuestions this post answers
How does Archfit detect architecture violations like forbidden module imports?
Archfit reads declared architectural intent from a .archfit.yaml file specifying module paths, public APIs, and internal boundaries, then uses language adapters to collect dependency evidence and an LLM-free decision layer to check it against the configured rules. A rule like public_api_only rejects cross-module access into internal paths, failing the archfit check command and CI when violated, with a machine-readable repair task generated for the agent. Developers hardening AI-agent workflows against architecture drift can track tools like this on daily.dev.
How does Vlad Khononov's Balanced Coupling model score coupling between two components?
It scores a relationship using three ordinal dimensions: integration strength (how much knowledge crosses the boundary, anchored 1 for contract coupling to 10 for intrusive coupling), distance (2 for same module to 9 for separate deploy units), and volatility (anchors of 1, 3, and 10, with 6 as a documented midpoint for medium volatility). The balance score is max(|strength - distance|, 10 - volatility) + 1, ranging from 1 (critical) to 10 (well balanced). Teams weighing coupling tradeoffs in modular systems can follow this kind of architecture thinking on daily.dev.
Why do AI coding agents tend to cause architecture erosion even when tests pass?
Coding agents make locally reasonable decisions within a small task context, such as importing directly from another module's internal persistence layer because the needed function was conveniently available there, and tests and linters do not check whether that dependency was architecturally allowed. Coverage confirms code executed, not that the boundary was respected, so the pull request looks clean while structural quality degrades one convenient import at a time. Developers relying on AI agents for feature work can keep up with architecture-governance practices on daily.dev.