The Architecture Rules a Linter Can't Check
The article discusses software architecture rules that go beyond what automated linters can enforce, such as ensuring services are appropriately sized, maintaining consistent patterns across modules, and validating design-level decisions through human review and architectural governance rather than code-level checks alone.
Background
- The author discusses architectural rules in software engineering that cannot be enforced by automated tools like linters (code-checking programs that flag syntax and style issues).
- These are high-level design principles such as "no circular dependencies between modules," "the database layer shouldn't call the UI layer," or "don't introduce unnecessary coupling" — rules that require human judgment about system structure, intent, and long-term maintainability.
- Unlike style rules (e.g., use tabs vs. spaces), architecture rules live in developer documentation, code review discussions, and architectural decision records (ADRs). They must be understood and followed by the team consciously, not automated away.
- The piece argues that relying solely on linters gives a false sense of control, and real architectural governance depends on team culture, shared understanding, and disciplined code review.