Signal #22：代码生成越便宜，理解系统越稀缺

代码正在变得越来越容易生成和修改。
一个任务可以在 Loop 中持续推进。测试失败后，Agent 会读取结果、继续修改并再次验证；多个 Agent 也可以同时处理不同模块。代码生成和修改的速度，由此不再完全受限于单个开发者的时间。

但软件不会因为代码更容易生成，就自然变得更容易理解。
当修改越来越多、执行越来越快，团队阅读代码、讨论设计和形成共同认知的速度却未必能够同步提高。系统仍然可以运行，测试也可能全部通过，但团队却越来越难回答一些基本问题：
为什么这里要这样设计？哪些边界不能改变？这层抽象解决的原始问题是什么？一次局部修改，会不会正在增加系统的长期成本？

**当代码越来越容易生成，还有多少人真正理解正在运行的系统？
**当越来越多的研发任务开始在 Loop 中持续运行，这个问题也就无法再被忽略。

Flask、Jinja2 作者 Armin Ronacher 在 《The Coming Loop》 中讨论了两层嵌套的 Loop。

**一层发生在 Coding Agent 内部。**Agent 读取文件、调用工具、修改代码并运行测试，再根据执行结果进入下一轮，直到它认为这次工作已经完成。

**另一层发生在 Agent 外部。**即使 Agent 已经停止，外部的 Harness 仍会继续检查结果，并决定是续接原来的 Session、补充上下文、重新启动一个 Session，还是把任务转交给其他执行单元。

Harness 可以理解为 Agent 外部的执行框架。它负责提供运行环境、工具和持久化状态，也会根据测试、规则或其他检查结果，判断整个任务什么时候才算真正结束。

简单来说：Agent 内部的 Loop 负责继续执行，外部的 Loop 负责判断任务是不是真的结束。

这套机制让任务可以跨越单次模型调用持续推进，也可能放大 Agent 原有的编码倾向。例如，Agent 遇到一个异常状态时，可能在出错位置增加一层判空、异常捕获或 Fallback，也就是主路径失败后的备用处理，让当前测试顺利通过。这次修改单独看往往合理。但更根本的解决办法，可能是收紧数据模型或状态约束，从源头避免非法状态出现。

Armin 的一个担忧就在这里：当前模型容易增加局部防御、复制已有逻辑或引入新的抽象，却不一定会主动建立更强的系统约束。当每一轮 Loop 都叠加一小块防御逻辑时，系统可能越来越容易通过当前检查，设计意图却逐渐被局部实现和历史补丁掩盖。

问题通常不会立即表现为功能失败。代码仍然可以运行，Agent 也可以继续修改，但团队开始越来越难解释：为什么这里存在三层兼容逻辑？这个抽象最初解决了什么问题？哪些分支来自真实业务约束，哪些只是过去某次任务留下的修补？

Addy Osmani 在 《Software Factories, Light and Dark》 中，将 Loop 的规模化运行放进了 Software Factory，也就是“软件工厂”的框架中。

在他的描述里，一座软件工厂由多层能力组成：

Review Gate 指的是任务或代码继续向下流转前，需要经过的检查与判断。这里既可以包含测试、静态扫描等自动化机制，也包括仍然依赖人类经验的架构判断和风险评估。

Addy 进一步用“亮灯工厂”和“黑灯工厂”描述同一套流程的两种运行状态。

亮灯模式同样可以高度自动化。Agent 负责实现，系统自动执行测试、扫描和部署，但关键设计、架构边界和高影响变更仍然有人理解，也保留了可以追溯的决策原因。

黑灯模式中的流程依然能够运行，代码也可以持续生成、检查和交付，但越来越少有人阅读具体实现，设计意图和历史原因也逐渐从系统中消失。

Addy 将由此产生的差距称为 comprehension debt，可以译作“理解债”：

代码不断增加，但人真正理解的部分没有同步增长。理解债不只是“代码难读”，也不等于系统规模大。当系统变化的速度超过团队维护设计意图、关键边界和因果关系的能力，理解债就开始形成。大型系统同样可以保持清晰：模块边界明确，重要决策有记录，历史约束可以追溯，变更影响也能够被解释。

真正危险的是另一种情况：隐式依赖不断增加，历史原因逐渐丢失，原有边界被局部修改绕过，而团队的共同认知没有同步更新。系统仍在演化，人却越来越难解释它为什么变成现在这样。

面对 Agent 执行中的不确定性，加强验证是最直接的工程方向。

Anthropic 在 《Building verification loops in Claude Code with skills》 中，介绍了如何把测试、Lint、运行检查和项目规则封装成可复用的 Skill，也就是 Agent 可以反复调用的项目级操作与检查规则。

Agent 完成修改后运行这些检查，失败就继续修复，再次验证，直到结果达到预设标准。不同开发者和不同 Session 因此可以复用同一套验证步骤，而不必每次重新提醒 Agent 应该检查什么。

Anthropic 还介绍了几种进一步的机制：

在 《How Anthropic secures its AI-native software development lifecycle》 中，Anthropic 称，目前约 80% 的合并代码由 Claude 编写。与此同时，团队也在将安全规则写入 CLAUDE.md 和组织级 Skill，让安全检查直接进入代码生成过程，并把人工参与保留在风险最高、影响最大的决策点。

这些机制很重要。缺少验证的 Agent，很难成为可靠的生产系统。

但验证能力与系统理解仍然是两件不同的事。

测试、Spec 和 Eval 可以将已经明确的目标、约束和验收标准，转化为可重复执行的检查。Eval 可以理解为：用一组有代表性的任务和评价标准，持续评估 Agent 的结果质量、行为表现和稳定性。它们能够覆盖的，主要是团队已经意识到，并且成功表达出来的部分。那些散落在历史需求、线上事故、性能限制、组织边界和过去架构决策中的判断，不会自然进入测试和验证体系。

为什么这里采用事件驱动，而不是直接调用？为什么两个看起来重复的数据结构不能合并？为什么某个服务必须独立存在？为什么这段逻辑宁愿增加一点复杂度，也不能引入共享状态？

这些问题很难只靠“检查是否通过”来回答。

Thoughtworks 的 Valentina Servile 在 《Should we still design code for humans?》 中也指出，良好的设计不仅方便人类理解，也会直接影响 Agent 修改代码的可靠性。面对耦合严重、命名混乱和业务逻辑重复的代码库，Agent 需要消耗更多上下文，也更容易作出错误假设。软件设计也无法只在 Spec 或架构图中一次性完成。耦合、内聚、重复和复杂度，最终仍然要在具体实现中被持续观察和判断。

验证可以告诉我们，系统是否仍然按照已经明确的规则运行；理解则要进一步回答，这些规则和边界是否仍然合理，当前实现是否值得继续保留和演进。

传统技术债通常来自短期交付与长期演进之间的权衡，也可能来自信息不完整、需求变化和早期设计假设失效。

理解债更加隐蔽。它可能产生在一个运行顺利的 Agent 系统中：代码通过测试，功能正常发布，任务也被标记为完成。因为没有明显失败，团队很难及时意识到系统认知正在流失。

当多个 Agent 并行推进任务，系统变化的速度就可能超过团队形成共同理解的速度。如果决策记录、架构同步和 Review 机制没有同步扩展，代码生成越快，理解债就越容易加速积累。真正被拉开的，不只是人类写代码与机器写代码之间的效率差距，还有：系统变化速度与组织理解速度之间的差距。

控制理解债，并不意味着回到逐行手写、逐行审查所有代码的工作方式。更现实的方向，是把“保持系统可理解”本身变成一项明确的工程能力。

高影响变更不应该等到大量代码生成完成后，才开始讨论方向是否合理。

在 Agent 执行前，团队需要先明确任务目标、系统边界、数据流、影响范围、关键风险和回滚方式。

未来 Review 的高价值对象，不只包括最终代码 Diff，也包括 Agent 准备如何改变系统的计划。

在代码大规模生成前审查关键决策，通常比事后检查和修改数千行代码更有效。

文档不能只描述系统现在是什么，还需要记录：为什么这样设计，依赖了哪些前提，保护了什么边界，以及在什么条件下可以改变。

架构决策、重要业务规则、历史事故和高风险约束，需要从少数人的个人经验，转化为人和 Agent 都能够检索、引用和更新的工程事实。

理解系统，不只是知道代码放在哪里，也包括知道一项设计为什么存在。

并不是所有任务都需要同样程度的人工介入。影响范围小、可以快速验证、失败后容易回滚的任务，可以交给 Agent 自动运行。跨模块、涉及关键数据、改变架构边界，或者长期成本难以立即判断的变化，则应该保留人工决策。

团队不需要在“完全人工”和“完全自动”之间做一次性选择，而应根据任务的影响范围、可验证程度、不确定性和可逆性，决定 Agent 可以获得多少自主权。

在这套体系中，不同工程资产承担着不同职责：

它们不能相互替代，但可以共同维护系统的可理解性。

AI Coding 会继续降低代码生成、修改和重写的成本。

过去因为开发投入过高而不值得建设的软件，可能会以更低的成本完成原型、实现和验证。与此同时，系统变化的数量和频率也可能随之上升。

但更多代码，并不会自动带来更多理解。

一个团队可以拥有更多 Agent、更高的交付速度和更完善的自动化检查，却仍然可能逐渐失去对核心系统的解释能力。

团队在 AI Coding 时代的长期竞争力，不会只体现在生成速度上，更取决于能否在扩大自动化的同时，持续保留对系统的判断能力、解释能力和演进能力。

代码可以生成，理解必须建设。

Agent 可以让代码越来越便宜，但理解一个持续变化的软件系统，依然昂贵。