AI coding assistants make bad architecture feel like steady progress, because every session reads the current code as the plan rather than as an accumulated drift.
The Details:
Each AI session starts cold. The model treats whatever shape the codebase already has as the intended design, then matches new code to that shape. If the last session introduced a small wander, this one reinforces it, and the system nudges further from its original boundaries with no one voting against it.
Green test suites are not proof of a healthy structure. Tests confirm current behavior, not whether that behavior still matches the intent the system was built around. A codebase can pass every check while three modules quietly implement the same idea in three different ways, and nothing in CI will flag that as a problem.
The warning signs show up as friction, not failure. A one field change that touches six unrelated files, a shrug when someone asks where a piece of logic lives, a team member saying a section is fragile and should not be touched: these are the architecture reporting that its seams have moved, long before anything actually breaks.
The fix is treating architecture as a maintained artifact, not a memory. Short decision records tied to the pull requests that caused them, invariants encoded as lint rules or tests, and a living file of load bearing constraints handed to every AI session all convert coherence from an assumption into something enforced. Without that, the team's mental model of the system decays faster than the code that implements it.
Bottom Line: Speed from AI tools is easy to measure and structural integrity is not, so coherence only survives if someone keeps insisting it matters more than the next quick patch.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
