Architecture Governance: Why Platform Thinking Beats AI Hype

Core Argument: Architecture Governance Is the Foundation of R&D Efficiency

The discussion opens with the assertion that software engineering quality and efficiency governance must be grounded in software architecture governance. Without this focus, R&D efficiency improvements hit a low ceiling. The speaker notes that at major 2024 conferences (K+ Summit, QCon), all large companies were still exploring AI for efficiency on old paths—decoupled from architecture governance—and none had produced real value.

DevXyzOps and Peripheral Tooling Are Insufficient

Various DevXyzOps practices essentially fail to touch the core of architecture governance, so their impact remains limited. Polishing the periphery while the internal "straw" remains unchanged yields limited overall efficiency gains.

The Difficulty Lies in Practice, Not Understanding

Architecture governance is hard not because it is poorly understood, but because practicing it—actually paying down technical debt from the software design level—is difficult to justify in business terms. The root cause is a failure to identify the true source of inefficiency and miscalculating the cost-benefit account.

AI as a Means, Not an End

In architecture governance, AI is merely a tool that makes previously hard governance tasks easier. The correct use of AI is to generate deterministic tools cheaply and quickly, because customers buy product determinism. The example of Claude Code is cited: less than 5% of its source code is AI-related, yet it delivers a deterministic product. Claims that "we shouldn't build tools, we should go AI-native" are characterized as hype to drive token consumption; those companies' actions contradict their rhetoric.

Return to Platform Thinking, Accelerated by AI

The fundamentals of architecture governance revert to traditional software platform thinking: building strong product determinism and rapid quality feedback loops on a layered logical and development architecture. AI lowers the time and cost to achieve these goals, but the playbook existed before AI.

Architecture Governance Is a Top-Level Engineering Commitment

Architecture governance is often a company's "number one engineering project"; without sustained leadership commitment, organizations inevitably revert to old patterns.

Developing Design Capability Requires Long-Term Training

Improving human design capability is challenging because it requires changing mental models. Architecture governance uses high cognitive density to impose order on code and suppress entropy. This skill cannot be taught quickly; it demands long practice, which explains the scarcity of true architects. Companies that do not prioritize architect development fail to build a talent gradient.

Concrete Case Study: Refactoring a 480k-Line System

Context: A client product of ~480,000 lines. Early 2024, the whole team used pure Claude Code but remained stuck in inefficiency.

Action: The author rewrote a critical module (configuration management, effectively the product's database). Custom code dropped from 65,000 lines to 15,000 lines, plus adoption of the open-source LittleFS filesystem (~6,000 lines, not counted in the 15k).

Result: Achieved high cohesion and low coupling; the module became easy to read and safe to modify for engineers of varying skill levels. Previously, the module caused field failures due to incorrect configuration reads.

Side Discovery: During the rewrite, an MCU driver bug was uncovered: cache-Flash data inconsistency after Flash writes, a notoriously hard-to-debug issue.

Dominant Design and the Distinction Between Refactoring and Rewriting

Quoting Grady Booch: "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." The author terms this "Dominant Design." Once dominant design is set, software quality is largely fixed; patching cannot qualitatively improve it. Evolution of dominant design requires continuous refactoring, yet many practitioners confuse refactoring with rewriting.

Human Cognitive Strengths vs. AI in Large Codebases

In a massive codebase, human brains are the bottleneck when reading code alongside AI. If humans do not understand code at the architectural level, they cannot govern the flood of AI-generated code, leading to "AI parasitism" rather than "AI mastery." Humans contribute intuition, systemic thinking, and global awareness (effectively infinite context)—areas where AI is weak.

Software Engineering as a Practice Discipline

The discussion concludes that software engineering, architecture design, and architecture governance are "Hard Parts" (referencing the Hard Parts pattern mindset). Improvement comes only through practice. System thinking grows by repeatedly facing problems, expanding the problem domain, and moving from local optima to global optima. Handling multiple complex systems is a proxy for the level of system thinking achieved.

References

Zhihu article on architecture governance practice: https://zhuanlan.zhihu.com/p/589725351 Zhihu article on Android architecture evolution and Pegasus architecture: https://zhuanlan.zhihu.com/p/1930324372343718672 WeChat article on "Hard Parts" pattern thinking:

https://mp.weixin.qq.com/s?__biz=MzI3NDYwMDM4MQ==&mid=2247486386&idx=1&sn=f5b0519cee69244ec1bdc48e5fcb6575&scene=21#wechat_redirect

WeChat article "Software Engineering Is a Practice Discipline":

https://mp.weixin.qq.com/s?__biz=MzI3NDYwMDM4MQ==&mid=2247484972&idx=2&sn=c015c4aae34f5538271c7380696ccff6&scene=21#wechat_redirect

Practical sharing on Zhihu:

https://zhuanlan.zhihu.com/p/2081390049430713421