AI changed your code but you can't tell what it did: Architecture drift is the real cost
As AI agents automate more refactoring, teams lose the ability to answer "what did the code become?" without costly manual review. Tools like Jin reintroduce architectural oversight at the moment of change, keeping human control over the structure AI writes.
AI coding agents routinely change many files at once, and while tests pass, the resulting architecture can drift silently. Dependency layering gets pierced, module boundaries blur, and responsibilities shift under the same names. The author, Zhang Yifan, argues this "architecture drift" is a growing cost in AI programming: line-level diffs can't show whether a new module appeared, whether a dependency was added, or whether an entity moved from one module to another.
Jin, a community fork of OpenCode, addresses this by maintaining a two-layer architecture model — L0 for systems, packages, modules, and external dependencies, and L1 for entities, fields, and relationships inside each module. Agents propose structural changes as editable snapshots, and a validation step checks references, public entities, and layering constraints. After applying, a drift check compares real code against the declared architecture, flagging unregistered symbols, misplaced entities, and missing module paths. Humans approve changes before they become part of the formal `arch/` definition.
The author is clear that Jin is not a proof of correctness and doesn't replace code review. It only makes structural change visible. But that visibility is exactly what's missing when a human is left staring at a diff of a dozen files, unable to say what the system became.
Soft constraints in prompts degrade as context grows; treating architecture as a set of hard, checkable facts is a more reliable way to govern AI-driven changes than static instructions.
Local optimal edits made by the agent, when aggregated, produce global structural chaos — a classic emergent failure mode of LLM-driven coding that no amount of testing catches.
Making structural changes explicit as a separate review step before writing to a formal architecture file preserves human judgment without slowing the agent down.
The distinction between "the same name, different responsibility" is subtle: semantic drift is the hardest form to catch with automated checks, yet it's the most dangerous for long-term maintainability.
A declarative drift checker is a pragmatic middle ground between no oversight and a full formal verification, acknowledging that architecture correctness is not the same as code correctness.