Architects Who Stop Writing Code Lose the Ability to Judge a System

The gap between design authority and implementation knowledge widens silently as engineers move into architecture roles. When the person with veto power over technical decisions no longer knows the codebase, teams absorb the cost: proposals get derailed by suggestions that are directionally correct but practically impossible to execute within the given constraints.

A common failure mode in technical reviews: an architect interrupts with a textbook best practice — a message center, a service mesh, an event bus — without knowing whether the system has one, what it would cost to build, or whether the business timeline can absorb it. The suggestion isn't wrong in principle; it's wrong because it substitutes industry patterns for knowledge of the actual code.

Architecture design depends on accurate judgment of the current state: where coupling is severe, what historical baggage exists, which changes are frequent. Documentation rarely captures this. The information lives in the code, and the only way to access it is to keep reading and writing code. Once an architect stops, the remaining inputs are industry practices and past experience — both valid references, but neither a substitute for knowing what the system looks like today.

The pattern surfaces most often in review meetings because that's the last place a non-coding architect still touches system details. A proposal triggers a memory of a pattern, and the suggestion comes out without the calibration that hands-on work provides.