Comprehension as an Architectural Characteristic: A System That Is Not Understood Cannot Evolve Safely 理解力作为一种架构特征：无法被理解的系统无法安全演进

The Comprehension Problem理解力问题

Seasoned teams on complex systems would have experienced production incident calls where most of the time goes into figuring out how the system is connected and what it actually does, rather than finding the bug. Eventually, the team ends up digging through the code to settle what the team’s collective memory couldn’t - how the system behaves. This problem arises as the understanding never expanded beyond certain individuals and outwards to others on the team(s).在复杂系统上工作的资深团队一定经历过生产环境事故排查，大部分时间都花在弄清系统如何连接以及它到底做了什么，而不是寻找 Bug。最终，团队不得不深入挖掘代码，以解决团队集体记忆无法回答的问题——即系统的行为方式。这个问题之所以出现，是因为理解从未从特定个人扩展到团队中的其他人。

In evolutionary architecture, systems should be designed to absorb and adapt to changing requirements and shifting landscapes. But to actually enable this adaptability, team members need a profound understanding of the system itself. As Peter Naur argued in Programming as Theory Building, it is not enough to simply understand the code; you have to understand the underlying "theory" held in the minds of the programmers who built it, "theory" being the mental model programmers build to understand how a program works. His claim is that the system includes the theory and not just the code. How widely and durably that theory is held across the team is therefore a property of the system itself. Margaret-Anne Storey expands on this idea in her paper From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI, where she defines three distinct kinds of system debt: technical, cognitive and intent. Cognitive debt is the silent loss of shared understanding of the system (loss of theory, as per Naur); intent debt is the lack of rationale for why the system is the way it is. Unlike characteristics like performance and availability, this property can deteriorate silently over time, and a system that is not understood cannot evolve safely. Because human comprehension holds both the what and why, it is a direct antidote to both cognitive and intent debt and must be recognized as an inherent architectural characteristic of evolutionary architecture.在演进式架构中，系统的设计应能吸收并适应不断变化的需求和环境。但要真正实现这种适应性，团队成员需要对系统本身有深刻的理解。正如 Peter Naur 在《编程即理论构建》（Programming as Theory Building）中所论证的那样，仅仅理解代码是不够的；你必须理解构建它的程序员头脑中持有的底层“理论”，即程序员为了理解程序如何工作而构建的心智模型。他主张系统不仅包含代码，还包含这种理论。因此，该理论在团队中保持的广度和持久性，本身就是系统的一种属性。Margaret-Anne Storey 在其论文《从技术债务到认知与意图债务：重思人工智能时代的软件健康》（From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI）中扩展了这一观点，她定义了三种截然不同的系统债务：技术债务、认知债务和意图债务。认知债务是指对系统共享理解的悄然丧失（即 Naur 所说的理论丧失）；意图债务是指缺乏系统为何如此设计的理由。与性能和可用性等特征不同，这一属性会随时间悄然恶化，而无法被理解的系统无法安全演进。由于人类的理解力涵盖了“是什么”和“为什么”，它是对抗认知债务和意图债务的直接解药，必须被视为演进式架构中固有的架构特征。

Three Forces That Erode Comprehension侵蚀理解力的三种力量

Related Sponsors相关赞助商

• Alert Fatigue Is Costing You: The State of Production Reliability and AI Adoption 告警疲劳正在让您付出代价：生产可靠性与人工智能采用现状

• AI Agents in Production: What It Takes to Move Beyond the Demo生产环境中的人工智能智能体：超越演示阶段需要什么

• Klaviyo Customer Agent: Building Bi-Directional Conversational Commerce at ScaleKlaviyo 客户智能体：大规模构建双向对话式商务

• Below the Framework: Why Agent Context Is an Infrastructure Problem (Live Webinar August 27, 2026) - Save Your Seat框架之下：为什么智能体上下文是一个基础设施问题（直播网络研讨会，2026 年 8 月 27 日）- 预留您的席位

• The Trust Lifecycle for Safe, Secure and Reliable AI Agents安全、可靠的人工智能智能体的信任生命周期

Related Sponsor相关赞助商

Explore the NeuBird AI Playground in a fully configured environment connected to live AWS telemetry. Try your first query!在连接到实时 AWS 遥测数据的完全配置环境中探索 NeuBird AI Playground。尝试您的第一个查询！

In complex systems maintained by multiple teams, centralized decision-making often creates bottlenecks and knowledge silos. Decisions queue behind a few people and knowledge concentrates with them. To combat these bottlenecks and truly enable an evolutionary architecture, organizations might shift toward decentralized architectural decision-making. While this optimizes flow and teams develop a deep expertise in their local sub-domains, the global picture fragments. Teams may understand how their service works, yet could lose the "why" behind where the systemic boundaries were drawn in the first place. Without shared governance and practices, local theories drift apart, deepening the organization’s knowledge fragmentation.在由多个团队维护的复杂系统中，集中式决策往往会造成瓶颈和知识孤岛。决策堆积在少数人身后，知识也随之集中。为了克服这些瓶颈并真正实现演进式架构，组织可能会转向去中心化的架构决策。虽然这优化了流程，团队也能在各自的本地子领域发展出深厚的专业知识，但全局图景却变得碎片化。团队可能了解自己的服务是如何工作的，却可能丢失了最初划定系统边界的“原因”。如果没有共享的治理和实践，本地理论就会产生分歧，加剧组织知识的碎片化。

Team churn also compounds this problem. When people leave the team, they take some of the "theory" away with them. New hires must rebuild the theory from scratch, aided by artifacts that generally record the what and not the why. Lacking the historical context of why certain boundaries exist, they might fall back to making tactical patches rather than systemic improvements matching the original design. In time, this erodes architectural integrity.团队人员流动也加剧了这个问题。当人员离开团队时，他们会带走一部分“理论”。新员工必须从零开始重建理论，而辅助他们的文档通常只记录了“是什么”，而非“为什么”。由于缺乏关于某些边界为何存在的历史背景，他们可能会退而求其次，进行战术性修补，而不是根据原始设计进行系统性改进。久而久之，这会侵蚀架构的完整性。

The latest and fastest of these three forces is GenAI. It reduced the implementation effort that used to generate comprehension as a byproduct, but that effort was also what built the mental model of the system in developers. Comprehension was naturally built and reinforced during the design, implementation, and verification phases prior to GenAI becoming prominent in software engineering. As this technology matures and delivery pressures become more pronounced than ever before, we see this tendency to deliver without comprehension creeping into enterprise software. During a feature demo to a client, an experienced engineer on one of our teams had to spend considerable time to understand how a piece of code she shipped a week before works, because she had never formed the mental model of it. The code passed every quality gate, but the demo was the first time the comprehension debt surfaced.这三种力量中最新且最快的是生成式 AI。它减少了曾经作为副产品产生理解力的实现工作，但正是这些工作构建了开发人员对系统的心智模型。在生成式 AI 在软件工程中变得突出之前，理解力是在设计、实现和验证阶段自然建立和加强的。随着这项技术的成熟，交付压力变得前所未有的明显，我们看到这种在没有理解的情况下进行交付的倾向正在潜入企业软件中。在一次给客户的功能演示中，我们团队的一位资深工程师不得不花费大量时间来理解她一周前发布的一段代码是如何工作的，因为她从未对其形成心智模型。这段代码通过了所有的质量关卡，但演示是理解力债务首次浮出水面的时刻。

A recent article from Arvind Narayanan and Sayash Kapoor talked about a software engineer's work being a "decide-execute-deliver" sandwich, with understanding being a pre-requisite for all three layers.Arvind Narayanan 和 Sayash Kapoor 最近的一篇文章谈到，软件工程师的工作是一个“决策-执行-交付”的三明治结构，其中理解力是这三个层面的先决条件。

Generative AI has compressed the middle layer, and we argue that the comprehension that used to come in all three layers should now be deliberately created at the two ends. This is where comprehension of the essentially complex parts has to form - before and after the "generative" phase. Software engineers must expend mental effort during these phases to connect designs and existing system structures to organize and create a mental model.生成式 AI 压缩了中间层，我们认为，过去在所有三个层面中产生的理解力，现在应该在两端刻意地创造出来。这就是必须在“生成”阶段之前和之后形成对本质复杂部分的理解的地方。软件工程师必须在这些阶段投入脑力，将设计和现有系统结构连接起来，以组织并创建心智模型。

Knowledge fragmentation, team churn, and AI-generated change - each erode comprehension at different speeds and lead to a system that cannot be safely changed.知识碎片化、团队人员流动和人工智能生成的变更——每一种力量都以不同的速度侵蚀理解力，并导致系统无法安全变更。

Detecting and Measuring Comprehension Loss检测和衡量理解力丧失

Architects and technical leaders can quantify the erosion of system comprehension by monitoring several key indicators. The natural instruments for this are fitness functions - they let architects express important architectural characteristics and verify them automatically. Automated fitness functions can measure some leading indicators of theory loss, but they cannot measure comprehension of intent itself. No pipeline check can confirm that a human understands why a change exists. The automation's job is to detect the conditions under which theory decays; the act of verifying that the change matches intent and that someone actually holds the theory of it belongs to the human checkpoint described in the next section.架构师和技术领导者可以通过监控几个关键指标来量化系统理解力的侵蚀。实现这一点的自然工具是“适应度函数”（fitness functions）——它们让架构师能够表达重要的架构特征并自动验证它们。自动化的适应度函数可以衡量理论丧失的一些领先指标，但它们无法衡量对意图本身的理解。没有任何流水线检查可以确认人类是否理解为什么存在某个变更。自动化的工作是检测理论衰减的条件；而验证变更是否符合意图以及是否有人真正掌握了相关理论，则属于下一节所述的人工检查点。

So, we have deliberately stretched the term. The "fitness functions" in the list below assess the sociotechnical system around the code, and only some are fully automatable. The rest are monitored indicators rather than executable checks, and in several cases that is a choice, not a limitation. Metrics about people change behavior when enforced - a gate that blocks a PR could be gamed to bypass the hurdle - enforce when gaming is hard or harmless and monitor otherwise. Treat thresholds as triggers for investigation rather than targets. Where a gate exists with an option to bypass, track the waivers and overrides so that thresholds can be corrected or team practices can be improved.因此，我们刻意扩展了这个术语。下表中的“适应度函数”评估的是代码周围的社会技术系统，只有部分是完全可自动化的。其余的更像是监控指标而非可执行检查，在某些情况下，这是一种选择而非局限。当强制执行时，关于人员的指标会改变行为——一个拦截 PR 的关卡可能会被绕过——在难以作弊或作弊无害的情况下进行强制，否则进行监控。将阈值视为调查的触发器，而非目标。在存在绕过选项的情况下，跟踪豁免和覆盖记录，以便纠正阈值或改进团队实践。

Figure 1: Comprehension must form before and after the execute phase
Source: author-created with draw.io图 1：理解力必须在执行阶段之前和之后形成 来源：作者使用 draw.io 创建

Code Review Dynamics代码审查动态

Pull Requests are a primary vehicle for knowledge sharing. Dysfunctional review metrics often point to a breakdown in shared understanding. Keep an eye out for these early warning signs:Pull Request (PR) 是知识共享的主要载体。功能失调的审查指标通常指向共享理解的崩溃。请留意这些早期预警信号：

• Large PR sizes: When a PR is too large to review, the knowledge flow it is supposed to carry does not happen. Enforce this by blocking large PRs (define the thresholds for your context). Ask the author to break down the PR and also catch this early in design review.大型 PR：当 PR 过大而无法审查时，它本应承载的知识流动就不会发生。通过拦截大型 PR 来强制执行此操作（根据您的上下文定义阈值）。要求作者拆分 PR，并在设计审查阶段尽早发现这一点。
• Agentic Code Reviewer: Do not let agentic code reviews be the sole reviewer of the PR - they can be the first reviewer, but it has to be followed by a human reviewer. Enforce this with policies such as CodeOwners.智能体代码审查员：不要让智能体代码审查成为 PR 的唯一审查员——它们可以作为第一审查员，但必须由人类审查员跟进。通过 CodeOwners 等策略强制执行此操作。
• Review Dysfunction: When review load falls on a handful of people or when the organizational dynamics deter reviewers from giving proper feedback to seniors, approval becomes a formality. This can only be monitored. Track the share of approved PRs having no substantive comments or with only ‘LGTM’, and the distribution of reviews across the team. Rotate reviewers and empower everyone in the team to review PRs, regardless of title. Make it explicit that challenging any author’s design or code is expected, including the architect’s.审查功能失调：当审查负担落在少数人身上，或者组织动态阻碍审查员向资深人员提供适当反馈时，批准就成了形式。这只能通过监控来解决。跟踪没有实质性评论或仅有“LGTM”的已批准 PR 的比例，以及审查在团队中的分布。轮换审查员，并授权团队中的每个人审查 PR，无论职位如何。明确表示，挑战任何作者的设计或代码都是被期望的，包括架构师的。
• Missing Design Reviews: Code changes with a large blast radius - the essentially complex core and seams - should always be preceded by a design review, regardless of the size of the change. This is difficult to enforce, so track PRs that touch core modules and get merged without a prior design review. Have the author give a team session on the design changes to make up for the lost design review opportunity.缺失的设计审查：具有巨大影响范围的代码变更（本质复杂的核心和边界）应始终在设计审查之后进行，无论变更大小如何。这很难强制执行，因此请跟踪触及核心模块并在没有事先设计审查的情况下合并的 PR。让作者进行一次团队会议来讲解设计变更，以弥补失去的设计审查机会。

Knowledge Distribution知识分布

Projects stall when a critical mass of context is held by too few engineers. Look out for instances where only one person holds the intent of the system. "Let's wait for Dave" should make the team sit up and take notice. Degree of Authorship (DOA) measures the amount of work a person contributes to the creation of a system. A high DOA implies the knowledge is concentrated around a few individuals. Note that DOA has its limitations; consider it as just one of the signals that can be used. Monitor it using tools like git-truck that can map knowledge distribution across a codebase and expose severe single points of failure. A low truck factor signals fragile system comprehension. Rotate developers working on such modules, add multiple owners to those modules, and conduct learning sessions.当关键的上下文知识掌握在极少数工程师手中时，项目就会陷入停滞。留意那些只有一个人掌握系统意图的情况。“等 Dave 来了再说”应该让团队警觉起来。作者贡献度 (DOA) 衡量一个人对系统创建的贡献量。高 DOA 意味着知识集中在少数个人身上。请注意，DOA 有其局限性；将其仅视为可使用的信号之一。使用 git-truck 等工具进行监控，这些工具可以映射代码库中的知识分布并暴露严重的单点故障。较低的卡车系数 (Truck Factor) 预示着脆弱的系统理解力。轮换在这些模块上工作的开发人员，为这些模块添加多个所有者，并进行学习分享会议。

Onboarding Friction入职摩擦

The time it takes a new hire to become productive is a direct proxy for system comprehensibility. If onboarding times are trending upward, the project's cognitive overhead is likely weighing on tenured team members too. Track the time it takes for the new hire to contribute to the design and architecture of the system, not just raise pull requests. Encourage new engineers to keep a log of confounding things - missing documentation, stale contracts, implicit dependencies. Review and address these findings on a periodic basis.新员工变得高效所需的时间是系统可理解性的直接代理指标。如果入职时间呈上升趋势，项目的认知负担可能也压在了资深团队成员身上。跟踪新员工为系统的设计和架构做出贡献所需的时间，而不仅仅是提交 PR。鼓励新工程师记录令人困惑的事情——缺失的文档、过时的契约、隐式依赖。定期审查并解决这些发现。

Lack of Documentation of Intent缺乏意图文档

Design decisions or changes without the accompanying 'why' can confuse even the creators over time. Documentation is an answer to "will someone who wasn’t here need it". Monitor the origin of such issues by detecting when a PR touches core or structural boundaries without adding an ADR or documentation for the rationale. Also track instances where changes to existing modules require unearthing the missing context. Address this by adding lightweight ADRs to capture the intent.没有附带“为什么”的设计决策或变更，久而久之甚至会让创建者感到困惑。文档是对“不在现场的人是否需要它”这一问题的回答。通过检测 PR 何时触及核心或结构边界而未添加 ADR（架构决策记录）或文档说明理由，来监控此类问题的来源。还要跟踪对现有模块的变更需要挖掘缺失上下文的情况。通过添加轻量级 ADR 来捕捉意图，从而解决此问题。

Domain Leakage领域泄漏

Changes that degrade architectural boundaries can make "local reasoning" impossible, and a seemingly isolated change has unintended side effects in an unrelated area. Use architectural fitness functions to fail the build if constraints are violated, and if so, redesign the interfaces or dependencies.破坏架构边界的变更会使“局部推理”变得不可能，一个看似孤立的变更会在不相关的领域产生意想不到的副作用。如果违反了约束，请使用架构适应度函数使构建失败，如果是这样，请重新设计接口或依赖关系。

Comprehension Checkpoint理解力检查点

A human reviewer cannot just read the code and trust what it says about itself. The human review at this stage is a comprehension checkpoint, not a quality gate. Feedback sensors like fitness functions should catch bad output, and the human is there to hold the intent, to build the theory of what the change does and why. This is why design reviews are more important than code reviews in agentic engineering flows.人类审查员不能只阅读代码并相信它对自己所说的内容。此阶段的人工审查是一个理解力检查点，而非质量关卡。像适应度函数这样的反馈传感器应该捕捉糟糕的输出，而人类的作用是掌握意图，构建关于变更内容和原因的理论。这就是为什么在智能体工程流程中，设计审查比代码审查更重要的原因。

There is a core difference in an engineer understanding a module during design and implementation vs after it was generated - that is the difference between active and passive thinking. When you solve a problem actively without having a solution readily available, it leads to creative solutions and ideas that are relevant to the context. This helps in evolving the system in an organic manner, driven by decisions relevant for the business domain and constraints. If code reviews and verification are the only places where our comprehension is sought, then comprehension never really forms. Pre-hoc comprehension ensures that humans remain in control of the system being constructed. Post-hoc comprehension implies that you will no longer be deciding the design of the system; since there are numerous ways in which the system can be built, and if you are not taking the decision upfront, you will end up with a statistically default design that the LLM was trained on, not the one your context demands.工程师在设计和实现过程中理解模块与在代码生成后理解模块之间存在核心差异——这就是主动思维与被动思维的区别。当你主动解决一个没有现成方案的问题时，它会带来与上下文相关的创造性解决方案和想法。这有助于以有机的方式演进系统，由与业务领域和约束相关的决策驱动。如果代码审查和验证是我们寻求理解力的唯一地方，那么理解力就永远不会真正形成。事前理解确保人类保持对正在构建的系统的控制。事后理解意味着你将不再决定系统的设计；由于系统有多种构建方式，如果你不预先做出决定，你最终会得到 LLM 训练所基于的统计默认设计，而不是你的上下文所要求的设计。

This does not mean that every change has to follow this process. It still makes perfect sense to delegate grunt work to AI, with the reviewer needing to know just enough to verify the output, and not really elevate it to a shared understanding. Decide when to hold the theory for the essentially complex core, and when to let go.这并不意味着每一个变更都必须遵循这个过程。将繁琐工作委托给人工智能仍然非常有意义，审查员只需要知道足够的信息来验证输出，而不必将其提升到共享理解的层面。决定何时为本质复杂的核心保留理论，何时放手。

Any system has to be understood, designed, built, validated, and maintained, even if parts of this flow get expedited as technology evolves. Teams should start by validating the requirements and ensuring they are unambiguous and testable, with documented acceptance criteria, before letting the agents code. This is not a call for big upfront design, as the unit here is a user story and not the entire system. With agentic engineering, the decide-execute loop runs faster, and the human engineer has to hold the intent of the change - what is changing and how the behavior changes at the boundaries - so that construction can be delegated without losing the theory.任何系统都必须经过理解、设计、构建、验证和维护，即使随着技术的发展，流程中的部分环节被加速。团队应该首先验证需求并确保它们是明确且可测试的，并带有已记录的验收标准，然后再让智能体编写代码。这不是呼吁进行大规模的前期设计，因为这里的单位是用户故事，而不是整个系统。在智能体工程中，决策-执行循环运行得更快，人类工程师必须掌握变更的意图——什么在变化以及行为如何在边界处变化——以便在不丢失理论的情况下委托构建工作。

Have the engineer explain the code in their own words, and carry that explanation into the PR description and the merge commit message. The value lies entirely in producing the commit message / PR description manually, instead of having an agent generate it automatically. The friction of writing the message is the probe for the author to find out if they hold the theory or not.让工程师用自己的话解释代码，并将该解释带入 PR 描述和合并提交消息中。其价值完全在于手动生成提交消息/PR 描述，而不是让智能体自动生成。编写消息的摩擦力是探测作者是否掌握了理论的探针。

Sustaining the Shared Model维持共享模型

Individual comprehension, while necessary, is still not sufficient. When an engineer holds a simplified model of the system in their head, comprehension divergence is cheap to fix. But when sub-systems communicate, and different teams interact, the divergence of mental models is expensive. Bounded context seams are the most important areas where comprehension must be shared. An API schema, for example, explains the shape of the request and response, pre-conditions and authorization, but does not talk about the behavioral aspect of the contract - things like idempotency, retry-safety, ordering requirements, consistency, and delivery guarantees. That behavior is theory and must exist on both sides as a shared understanding. Tools and artifacts such as ADRs and context maps are necessary, but they don’t sustain comprehension by themselves. That shared model can be achieved only by enabling knowledge flow: maintaining deliberate team topologies, pairing and rotating engineers across modules so that the theory is not siloed with one engineer, and adopting decentralized architectural decision-making.个人理解虽然必要，但仍不足够。当工程师头脑中持有系统的简化模型时，理解力的偏差很容易修复。但当子系统进行通信，且不同团队进行交互时，心智模型的偏差代价高昂。有界上下文的边界是必须共享理解的最重要区域。例如，API 模式解释了请求和响应的形状、前置条件和授权，但没有谈论契约的行为方面——比如幂等性、重试安全性、顺序要求、一致性和交付保证。这种行为属于理论，必须作为共享理解存在于双方。ADR 和上下文映射等工具和工件是必要的，但它们本身无法维持理解力。这种共享模型只有通过促进知识流动才能实现：维护刻意的团队拓扑结构，在模块之间结对和轮换工程师，使理论不会被单一工程师孤立，并采用去中心化的架构决策。

Figure 2: Individual comprehension is necessary but not sufficient - it must flow onward to the team to survive churn.
Source: author-created with draw.io图 2：个人理解是必要的但不充分——它必须流向团队以抵御人员流动。 来源：作者使用 draw.io 创建

With GenAI, the knowledge silo issues are magnified. When agents produce code faster than humans can comprehend, the knowledge flow gets an additional first hop - between the agent and the individual. The person directing the agent must be able to explain the design - not by learning it from the generated output, but by reconciling what was implemented with the mental model they had during design. The comprehension checkpoint handles the agent-to-individual hop; the practices above sustain the individual-to-team flow that makes shared understanding durable. If comprehension is an architectural characteristic, then comprehension debt (the gap between what the system is and what the team understands it to be) is a liability that accrues interest. Like technical debt, it is not paid down in a single effort. The practices work only as recurring habits, and hence comprehension must be baked into the process in such a way that it is meant for the engineer who hasn’t joined yet.有了生成式 AI，知识孤岛问题被放大了。当智能体产生的代码速度超过人类理解的速度时，知识流动就多了一个额外的第一跳——在智能体和个人之间。指导智能体的人必须能够解释设计——不是通过从生成的输出中学习，而是通过将实现的内容与他们在设计时持有的心智模型进行协调。理解力检查点处理了“智能体到个人”的跳跃；上述实践维持了“个人到团队”的流动，使共享理解持久化。如果理解力是一种架构特征，那么理解力债务（系统现状与团队理解之间的差距）就是一种产生利息的负债。像技术债务一样，它无法通过单一努力偿还。这些实践只有作为重复的习惯才有效，因此必须将理解力以一种适合尚未加入的工程师的方式融入流程中。

Engineering Comprehension Deliberately刻意地构建理解力

Treating comprehension as an architectural characteristic means giving it what we give the others: leading indicators to watch, fitness functions to automate them, and practices that hold the line. If you discover the gap in comprehension only after the agent-generated code is in production, you've already lost the cheap option. Fragmentation, churn, and generative AI each widen that gap at their own pace, and none of them announces itself - the system keeps passing its gates while the theory behind it thins unseen. So make comprehension deliberate at the seams and at the core domains and wherever the system should be evolvable.将理解力视为一种架构特征，意味着给予它我们给予其他特征的东西：要观察的领先指标、要自动化的适应度函数，以及守住底线的实践。如果你在智能体生成的代码进入生产环境后才发现理解力的差距，你已经失去了廉价的选项。碎片化、人员流动和生成式 AI 每一种都在以自己的速度扩大这一差距，而且它们都不会自我宣布——系统继续通过其关卡，而其背后的理论却在无形中变得稀薄。因此，要在边界、核心领域以及任何系统应该可演进的地方，刻意地构建理解力。

Evolutionary architecture promises systems that absorb change safely. That promise is only as good as the shared understanding underneath it, and understanding only survives when it is deliberately and continuously engineered.演进式架构承诺系统能够安全地吸收变化。这一承诺的好坏取决于其底层的共享理解，而理解只有在被刻意且持续地构建时才能存续。

About the Authors

Jacobus Meintjes

I am a Lead Solution Architect with a passion for solving complex technology challenges and helping teams deliver meaningful business outcomes. My experience spans enterprise platforms, cloud computing, distributed systems, and financial services, where I design solutions that balance innovation with practical implementation. I am particularly interested in generative AI, software architecture, and how emerging technologies are changing the way we build software.

Show moreShow less

Narayana Rengaswamy

Narayana Rengaswamy is VP of Architecture at Optym, where he oversees the technical direction of a portfolio of B2B SaaS products built for planning and execution in the transportation logistics space. A software engineer for 19 years, he specializes in distributed systems, domain-driven design, and event-driven architecture, and designs reliability-critical systems on Azure. He works across engineering, product, and platform teams to create decision support systems that embed complex optimization logic into production-grade software.

Show moreShow less

Paul Katsande

Paul Katsande is a software engineer and architect with over a decade of experience building distributed, event-driven systems for organisations in various industries including finance, defence, and broadcasting. He specialises in Scala, Java, and cloud-native platforms, with recent focus on machine learning and generative AI. Paul holds post-graduate qualifications in engineering from the University of Manchester and an Executive MBA from Quantic.

Show moreShow less

Sureshbabu Bikki

Suresh Bikki is Head of Engineering, Architecture at Onafriq, Africa's largest payments network, where he leads the architecture function behind the company's pan-African payments infrastructure. He specialises in designing large-scale distributed systems, payment rails, and integration platforms that connect mobile money operators, banks, and global partners across the continent. With deep expertise in systems architecture and engineering leadership, Suresh focuses on building resilient, scalable technology that helps make borders matter less for the millions of people and businesses moving money across Africa.

Show moreShow less